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ABSTRACT 


The term probe effect denotes behavioral changes caused by introducing delays into 
a concurrent program with synchronization errors. This thesis investigates the feasibility of 
developing discrete-event simulation (DES) models of software architectures to perform 
software testing free of the probe effect. 

A message-passing subsystem (MPS) and simulated MPS (SMPS) were developed 
in Java that runs with the same application code. An MPS platform-performance model 
(MPPM) was developed using dual-loop benchmarking and was integrated into the SMPS. 
Two demonstration programs were developed to study SMPS timing and its model of a 
preemptive multi-threaded run-time system. The SMPS-based program behavior was com¬ 
pared to hypothetical execution on a platform with a perfect system clock and no execution 
overhead. 

The differences between hypothetical and observed SMPS-based execution were 
found to correctly reflect the MPPM. The results indicated that it is feasible to develop DES 
implementations of some software architectures to perform software testing. 
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1. INTRODUCTION 


Concurrent programs are used increasingly in modem software systems. Modem 
high-level programming languages such as Java and Ada have facilities for concurrency 
control built into the language. This provides the opportunity to develop transportable con¬ 
current programs. Such programs must often meet timing requirements and are typically 
more complex than their sequential counterparts. More frequent design and implementation 
errors usually accompany additional complexity. More and better software testing can re¬ 
duce this problem. However, invasive testing techniques that save or display program state 
can change timing in concurrent programs by consuming additional CPU time and by al¬ 
tering synchronization relationships with operations such as lO blocking, preemption, or 
breakpointing. The term probe effect denotes behavioral changes caused by introducing de¬ 
lays into a concurrent program [Gait 1986; McDowell and Helmbold 1989; Fidge 1993; 
Shutz 1993]. The probe effect presents a serious challenge to software testers since it can 
cause a program to generate different results depending on whether it is being tested. 

A. RESEARCH QUESTIONS 

The thesis is concerned with two questions related to avoiding the probe effect in 
testing real-time software implemented in high-level languages (HLL) developed using 
Object-Oriented Analysis (00A). The uniprocessor question is whether it is feasible to de¬ 
velop a simulation model of an application-independent software-architecture and environ¬ 
ment in which to execute the same (HLL) application-level binary code as would execute 
in the target environment. The distributed-systems question is whether it is feasible to de¬ 
velop such an approach to support execution of distributed real-time applications. 
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The capability to execute the same HLL application code in both a simulation mod¬ 
el and in its target environment would enable application-level software testing to be con¬ 
ducted under controllable conditions free of the probe effect. Implementations of the same 
software architecture (SA) that generate the same program results with the same applica¬ 
tion-level binary-code have application-binary-code consistency (ABCC). The require¬ 
ment that the same application code execute in both environments implies that both 
implementations have ABCC and that they have the same interface. If the software-archi¬ 
tecture were free of application-content, it would yield a reusable software-architecture for 
testing and executing real-time applications. Having a capability that relied only on a single 
HLL for timing and synchronization would produce highly portable and testable software. 
Both the simulation model and the application software for the target system would be in¬ 
dependent of the operating system and hardware platform. 

The capability to execute distributed real-time applications in both environments 
supports the testing of multiple communicating application instances under conditions that 
are free of the probe effect. This would enable software testers to cover previously unat¬ 
tainable test cases by increasing the amount of control they have over the test environment 
for distributed systems. 

B. METHODOLOGY 

As part of the investigation presented in this thesis, two implementations of the 
same software-architecture were developed. The first is an object-oriented, multi-threaded, 
asynchronous, message-passing subsystem (MPS). The second is a sequential, discrete- 
event simulation (DES) model of the MPS (SMPS). 

Two design goals drove the development of MPS and SMPS. First, they must have 
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the same interface so that applications, if properly implemented, can execute unmodified 
on both. The SMPS must also have the same message transmission and reception order as 
the MPS to the extent that the MPS run-time environment is deterministic. 

Since timing characteristics are largely a function of the run-time environment, the 
SMPS was parameterized to accept a platform-performance model. A platform perform¬ 
ance-model acquisition method was developed using a dual-loop measurement technique 
[Clapp et al. 1986; Altman and Weiderman, 1987; Vestal, 1990] to acquire language feature 
execution time estimates. 

Two demonstration programs were also developed. An implementation of the “Din¬ 
ing Philosophers” program [Dijkstra 1971] was developed to test the timing and synchro¬ 
nization features of the simulation model. The second is an MPS-based program with Rate 
Monotonic Scheduling (RMS) priority assignments and artificial workloads [Sha and 
Goodenough, 1990]. This program was developed to study SMPS timing and the model of 
a preemptive multi-threaded run-time system. 

C. OVERVIEW OF THE THESIS 

Chapter II of the thesis presents background material consisting of brief overviews 
of related approaches to addressing the probe effect, relevant aspects of DES modelling, 
and OOA. Chapter III describes the operational models and design of the MPS and SMPS 
and addresses issues related to SMPS fidelity. Chapter IV describes platform performance- 
model development. Chapter V presents descriptions of the demonstration programs and 
discusses their results and implications for distributed systems. Finally, Chapter VI 
presents the conclusions, discusses relevance to other application areas, and presents rec¬ 
ommendations for further research. 


Appendix A contains the OOA model diagrams for the MPS and the SMPS and 
sample OOA model diagrams for a simulated distributed MPS (SDMPS). Appendix B con¬ 
tains MPS and SMPS source code examples. Appendix C contains the “Dining Philoso¬ 
pher” OOA model diagrams. Appendix D contains selected sections of the execution traces 
for the Dining Philosophers and RMS programs. 
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11. BACKGROUND 


This chapter provides background on approaches to addressing the probe effect and 
explains its significance for software testing. It also provides background on simulation 
modelling and defines the approach used in the current investigation. Finally, it describes 
the derivative of OOA used in the development approach. 

A. THE PROBE EFFECT 

Probe effect delays are delays caused by intrusive techniques such as running the 
program in a debugger and by source code instrumentation in testing. Delays may also be 
introduced by operating system effects [Gait 1986] and by other sources of non-determin¬ 
ism such as communication protocols [Tannenbaum 1996]. Gait states that the probe effect 
often manifests itself in two ways [Gait 1986]. Either a non-functioning program begins to 
operate as desired when delays are inserted or an apparently working program yields incor¬ 
rect results with inserted delays. There are also two other ways the probe effect can mani¬ 
fest itself One is when a program that previously gave incorrect results yields different 
incorrect results with inserted delays. The other is when a functioning program gives dif¬ 
ferent correct results with inserted delays. Although this thesis is concerned with the probe 
effect in software testing, most of the other work to eliminate or mitigate the probe effect 
addresses its role in debugging. 

Netzer and Miller state that two messages in a message-passing parallel program 
can race if they are simultaneously in transit and either could arrive first at some receive 
operation [Netzer and Miller 1994]. Lamport defines the happened before relation and con¬ 
current as follows [Lamport 1978]: 
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Definition. The relation on the set of events of a system is the 
smallest relation satisfying the following three conditions: (1) If <3 and b are 
events in the same process, and a comes before b, then a-^b. (2) If a is the 
sending of a message by one process and b is the receipt of the seime mes¬ 
sage by another process, then a^b. (3) If a^b and b->c then a^c. Two 
distinct events a and b are said to be concurrent if -\{a^b) and -i(b^a). 

Netzer and Miller’s racing messages are examples of Lamport’s concurrent events. 
A synchronization error exists if the arrival order of two racing messages affects program 
correctness [Netzer and Miller 1994]. The probe effect adds to the risk that actual test cases 
may not implement test case design by affecting the arrival order of racing messages. 

When a race is detected, the logical time of the message receipt is traced, or record¬ 
ed. Traced times accompany racing messages and during re-execution, message receipt for 
racing messages is restricted to the traced time from a previous execution. This approach is 
more efficient than other trace and replay schemes that constrain all message receptions to 
traced times. However, it maintains the same synchronization properties as the original ex¬ 
ecution by preserving the happened before relation [Netzer and Miller 1994]. 

Jain et al. used intrusive techniques to monitor timing behavior for real-time sys¬ 
tems [Jain et al., 1996]. The approach maintains local time as the value pair {CT, A), where 
CT is the clock time obtained from the internal clock, and A is the current intrusion time. In 
this case intrusion time is the CPU time consumed by executing the monitoring instructions 
on the same CPU. The estimate of clock time, given as CT-A, replaces clock time in timing 
computations. This prevents the probe effect from affecting program results. This approach 
uses a model of actual clock time and requires accurate knowledge of the timing properties 
of monitoring operations. 

Reproducibility, like the term test repeatability, describes whether a program com¬ 
putes the same results when repeatedly executed with the same inputs [Schutz 1993]. One 


6 



way to avoid the probe effect in debugging is to permanently install debugging probes in 
the program so the program undergoing debugging is the same as the final version [Mc¬ 
Dowell and Helmbold 1989; Fidge 1993]. Practical debugging problems attributed to the 
probe effect are often manifestations of the difficulty of achieving reproducibility [Fidge 
1993], 

In Timewarp, there is one local virtual clock per process and messages to be sent 
are timestamped with the virtual time when they must be received. Local virtual time is up¬ 
dated to the timestamp of the next event in the process input queue. When a process re¬ 
ceives a message, m, with a receive-time that is earlier than its local virtual time, its state 
and local virtual time are restored to tm’s receive-time and any synchronizing actions it per¬ 
formed since that time are undone [Jefferson 1985]. 

Tolmach and Appel developed an interactive debugger with reverse execution for 
the language Standard ML [Tolmach and Appel 1991]. This debugger associates the value 
of a software instruction counter, a so-called s-time, that is incremented each time a debug¬ 
ger breakpoint or periodic checkpoint is encountered. Since this approach was highly vul¬ 
nerable to the probe effect, they proposed a model of concurrency debugging based on the 
Timewarp system [Jefferson 1985], This proposal includes the concept of a virtual multi¬ 
processor consisting of a number of virtual processors. Each virtual processor would be 
characterized by an execution rate and its current s-time would be substituted for Time- 
warp-style local virtual time. The system would compensate for probe effects by rolling 
back operations that violate the total ordering of synchronizing operations as defined by s- 
times. By varying the specified number and execution rates of virtual processors one could 
obtain data from different program runs that would help expose time-dependent behavior 
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[Tolmach and Appel 1991]. 

Huang developed a soft>vare simulator of a 4MHz Z80 processor designed to exe¬ 
cute programs in machine code to facilitate testing and debugging of real-time programs 
[Huang et al. 1983]. This avoided the problem that traditional debuggers have of handling 
interrupts. It also avoids the problem that real-time simulators have of being required to 
process large quantities of mostly irrelevant data. This is another example of an approach 
that uses a model of time to avoid the probe effect. Similar approaches are often used for 
testing real-time control systems. 

The significance of the probe effect and unpredictable delay insertion for software 
testing is the adverse effect on observability and controllability [Shutz 1993]. The probe ef¬ 
fect adds to the risk that actual test cases may not implement test case design. The goal of 
software testing is to find errors and a successful software test is one that reveals an error 
[Myers 1979]. Debugging has been described as diagnosis and correction performed after 
executing a successful test case [Myers 1979; Shutz 1993]. The impact of the probe effect 
on software testing is more closely related to controllability than reproducibility, but the re¬ 
verse is trae for debugging. 

Gupta’s approach accurately reports timing information by compensating for probe 
effect intrusion time [Gupta et al. 1996]. However, the approach does not address reproduc¬ 
ibility or controllability needed for testing. Netzer and Miller’s approach requires the de¬ 
velopment of a debugger. This makes portability costly [Netzer and Miller 1994]. Tolmach 
and Appel’s approach also has limited portability because it is restricted to the Standard 
ML language. Huang’s approach requires development of a virtual processor for each re¬ 
quired processor type [Huang et al. 1983], also making portability a difficult problem. It 
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require access to the operating system machine-code for each target. 

The approach presented in this work assumes the existence of two versions of a test¬ 
ed and debugged application-independent software-architecture and a performance model 
generation program. Testing the software on another platform should only require genera¬ 
tion of a new performance model. Actual testing can be performed on any platform that can 
support the simulation model using the newly acquired performance model as input. 

B. DISCRETE-EVENT SIMULATION 

Russell defines simulation as follows: “A simulation of a system is the operation of 
a model-that is a representation of the system” [Russell 1983]. Models of systems may be 
continuous or discrete depending on the model of changes in system state [Graybeal 1980]. 
Models of systems may also be stochastic or deterministic. Stochastic models contain a cer¬ 
tain amount of randomness. In deterministic models the system evolves completely deter¬ 
ministically from one state to the next [Graybeal 1980]. 

Most discrete simulation tools have either a time-driven or an event-driven clock 
(EDC) policy. A time-driven policy usually consists of repeatedly incrementing the clock 
with a fixed time quantum and then servicing all events scheduled to occur at that simula¬ 
tion time. In such cases, the time quantum is the clock granularity. An EDC policy usually 
can be implemented by repeatedly removing the event from the event set with the earliest 
activation-time, updating the clock to the time of that event, and then servicing that event. 
Events are often serviced by executing an event-subprogram. An event-subprogram is a 
subprogram that models the behavior of one or more events occurring at an instant in time. 
The Java method named current, activate shovra in Fig. 2.1 is an example of an event-sub¬ 
program. 
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DES models may also be process-oriented or event-activation-oriented. ^ SIM- 
SCRIPTII.5 [Russell 1983], Simula 67 [Birstwistle et al. 1973], and the Ada Process-Ori¬ 
ented Simulation Library (APOSL) [Ollerton 1992] are examples of process-oriented DES 
systems. Process-oriented systems have a concept of a process and may have state and a 
lifetime. The process reacts to events that may cause it to perform an action, simulate the 
passage of time, become suspended or interrupted, and so on. In an event-activation-orient- 
ed system instantaneous events occur at scheduled times in a model. Occurrences of such 
events and the separations in time between them can be functionally equivalent to the life- 
cycle of a process in a process-oriented system. 

In general, process-oriented approaches require more resources than event-activa¬ 
tion-oriented approaches, but processes are very convenient modelling abstractions for en¬ 
tities with life-cycles. However, they generally consume more memory and CPU time than 
event-activation-oriented approaches due to the necessity to save and switch execution con¬ 
text during process state transitions. 

In a DES model, a positive difference in time between the occurrence of two suc¬ 
cessive events represents the passage of time. It is commonly used to represent the duration 
of an action. A DES-action represents activity occurring over a finite positive amount of 

public static void EDC_Loop(){ 
current = nextEventO; 
while (current != null){ 

clock = clock + current.activation_time; 
current.activate(); 
current = nextEventO; 

} 

} 

Figure 2.1. Example of a Java Implementation of an EDC Policy 

1- The term event-activation-oriented is used since there does not appear to be a single commonly 
used term to describe this approach. 
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time modelled by the occurrence of two events denoting the beginning and end of the ac¬ 
tion. DES-action-time is the difference between the activation-times of these events. The 
granularity of DES-action-time impacts model fidelity, performance, and development ef¬ 
fort of DES simulation models. 

During this work a minimal event-activation-oriented DES library with an EDC 
policy was developed in Java to support a deterministic model of the MPS running in a pri¬ 
oritized, preemptive, multi-threaded environment. 

C. OBJECT-ORIENTED ANALYSIS 

Rumbaugh states that the term object-oriented means organizing software as a col¬ 
lection of discrete objects that incorporate both data stmcture and behavior [Rumbaugh, et 
al., 1991]. Inheritance and polymorphism are two properties that are also associated with 
object-orientation. Inheritance refers to the object-oriented property that when descendents 
of types are defined through type extension or specialization [Rumbaugh et al. 1991] they 
inherit the characteristics of the ancestor type. Polymorphism describes the property of de¬ 
scendents having different implementations of an operation that is defined in the ancestor 
type. Different implementations of a polymorphic operation must have the same signature, 
that is, the same number and types of arguments and the same result type [Rumbaugh et al. 
1991]. 

The term Object-Oriented Analysis was first used to denote the Shlaer and Mellor 
method (SMM) “for identifying the significant entities in a real-world problem and for un¬ 
derstanding and explaining how they interact with one another” [Shlaer and Mellor 1988]. 
This consists mainly of producing a set of information, state, and process models by apply¬ 
ing the rules of the method [Shlaer and Mellor 1988; Lang 1993; Shlaer and Langl996]. 
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The term 00A is now commonly used to denote object-oriented high-level design and anal¬ 
ysis methods for software engineering. 

The SMM distinguishes itself from other OOA and object-oriented design ap¬ 
proaches in three ways. First, objects are abstractions of real-world things in the application 
domain as opposed to representing conceptual entities of the design [Shlaer and Mellor 
1997]. Second, analysis proceeds by separating systems into various domains, or subject 
areas, that are analyzed separately. These are the application domain, various service do¬ 
mains, the software-architecture-domain, and other architecture-domains. Finally, SMM is 
a translation-based method, as opposed to being elaborative [Bell 1998]. In an elaborative 
method such as Object Modelling Technique (OMT), object design is a process of adding 
detail to existing models and making implementation decisions [Rumbaugh et al. 1991]. 
SMM translation is a more elaborate process. 

SMM translation requires application analysis, architecture, an application-in- 
stance-to-architecture-instance mapping, and a system-construction engine. SMM analysis 
“consists of work products that identify the conceptual entities of a single domain and ex¬ 
plain, in detail, the relationships and interactions between these entities” [Shlaer and Mellor 
1997]. These consist primarily of a domain model, an object information model (OIM) for 
each domain, a state-model for each active object in each OIM, and an action data-flow di¬ 
agram (ADFD) for each action of each state-model. An active object is an object with in¬ 
teresting behavior. Architecture deals completely with the following concerns: 

• policies and mechanisms for organizing and accessing data; 

• control strategies, including synchronization, concurrency, interactions in a dis¬ 
tributed system, and the like; 

• structural units-the tasking strategy for the system, strategies for allocating 


12 



tasks to processors and processing units to tasks, standard structures used with a 
task; and 

• time—mechanisms for keeping time and for creating delayed transfers of control. 
[Shlaer and Mellor 1997]. 

Archtypes are much like macros and provide the application-instance-to-architec- 
ture-instance mapping. “An archt5^e combines text, written in the target programming lan¬ 
guage, with placeholders used to represent information from the architecture’s instance 
database” [Shlaer and Mellor 1997]. An instance database is a database containing infor¬ 
mation about preexisting instances from the associated domain. A system-construction en¬ 
gine is “a script... that will generate the code for the system from the analysis models, the 
archtypes, and the instance databases of all domains” [Shlaer and Mellor 1997]. 

SMM translation requires an architecture-independent analysis expressed in com¬ 
plete detail and compliant with the rules [Shlaer and Mellor 1988; Lang 1993; Shlaer and 
Lang 1996] of the method [Shlaer and Mellor 1997]. It also requires an application-inde¬ 
pendent architecture also expressed in complete detail in both conceptual and archtype 
terms” [Shlaer and Mellor 1997]. The system-construction engine takes the instance data¬ 
bases and analysis models as input and expands the archtypes to produce the code. 

The SMM method is relatively formal [Shlaer and Mellor 1988; Lang 1993; Shlaer 
and Lang1996] and requires a considerable investment of effort to produce a complete set 
of archtypes for the architecture-domain and a complete set of models for multiple do¬ 
mains. This is likely to be more expensive than elaborative approaches for one-time devel¬ 
opment efforts. It is also likely to be relatively expensive when applied to problems with 
volatile requirements. In his summary on translative approaches. Bell commented that 
“The key determinant is the potential return from reusing the architectures” [Bell 1998]. 
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A complete application of the SMM is impractical for this effort. The models pre¬ 
sented in this work are primarily for descriptive purposes. However, the development ap¬ 
proach used in this thesis is similar to the SMM in the following ways. First, it views 
application and architecture as separate analysis problems. Second, objects represent con¬ 
ceptual entities in the analysis domain, as opposed to design entities. Finally, it uses state 
machines, as opposed to OMT state-charts, to model system dynamics. 

The SMM defines action time as the time required to execute a state-model action 
[Shlaer and Mellor 1992]. In order to avoid confusion with DES-actions and DES-action- 
time, state-model action and state-model action time will be referred to from here on as SM- 
action and SM-action-time. 

Huang’s Z80 simulator referred to in section A above [Huang et al. 1983] could 
have been implemented as a DES model with an EDC policy and default granularity of one 
CPU cycle. The three main capabilities required to achieve this are the capabilities to fetch 
the next instruction, to execute the instruction, and to update the clock. Figure 2.2 shows 
how a hypothetical EDC-loop could be implemented in Java to achieve this. 

This approach could also be viewed as state machine execution. Each SM-action 
corresponds to a DES-action and SM-action-time corresponds to DES-action-time from 
this viewpoint. This correspondence is highly desirable because it allows the application 


public static void Z80_Loop(){ 
current = fetchinstruction(); 
while (current != null){ 
current.execute() ; 

clock = clock + current.clock_cycles; 
current = fetchinstruction(); 

} 


Figure 2.2. Java Code Fragment of a Hypothetical Z80 Simulator 
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source code to execute in the simulator unchanged. However, it also requires more EDC- 
loop overhead than the latter approach. 

The portability problems mentioned in section A limit the usefulness of machine- 
code-level modelling of programs written in HLLs with built-in concurrency such as Java 
or Ada. Unfortunately, HLL statement-level modelling for such languages is likely to be 
unsatisfactory for concurrent programs. It would raise the level of abstraction and achieve 
greater portability at the expense of model fidelity because single HLL statements can mask 
complicated interactions. 

D. DEFINITION-USE PATHS WITH RESPECT TO THE CLOCK 

Figure 2.3 graphically depicts the views of time in SM-action and DES-action exe¬ 
cution of the same n statements. In each case, the value of the internal clock is t„ after n 
statements have completed execution. However, after statement sq has executed, the value 
of the internal clock is U in the SM-action and is still tg in the DES-Action. In the SM-ac- 
tion, each statement is viewed as consuming a quantity of time as indicated in the time col- 
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Figure 2.3. Correspondance of Real Time and Simulation 
Time in SM-action and DES-Action Execution 
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for the SM-action. However, the DES-action time column shows that no simulation 

elapses between statement executions in the DES-action. 

Clarke defines a module to be either a main program or a single subprogram that has 

one entry and one exit point and defines control flow graph as follows. 

A control flow graph of a module M is a (not necessarily unique) di¬ 
rected graph G(M) = (N, E, n^, n^, where N is the (finite) set of nodes, E c 
NX N'ls the set of edges, 6 is called the start node, and nj-e N is called 
the final node. Each node in N, except the start node and the final node, rep¬ 
resents a statement fi-agment in M, where a statement firagment can be a part 
of a statement or a whole statement. [Clarke et al. 1989] 

Clarke defines PATH(M) as the set of all paths in G(M) [Clarke et al. 1989]. Jorgen¬ 
son refers to “a program P that has a program graph G(P), and a set of program variables 
V” in the following four definitions [Jorgenson 1995]. 

Node n € G(P) is a defining node of the variable v e V, written as 
DEF(v,n), iff the value of the variable v is defined at the statement fragment 
corresponding to node n. 

Node n € G(P) is a usage node of the veiriable v e V, written as 
USE(v,n), iff the value of the variable v is used at the statement fragment 
corresponding to node n. 

A definition-use (sub)path with respect to a variable v (denoted du- 
path) is a (sub)path in PATHS(P) such that, for some v € V, there are define 
and usage nodes DEF(v,m) and USE(v,n) such m and n are the initial and 
final nodes of the (sub)path. 

A definition-clear (sub)path with respect to a variable v (denoted dc- 
path) is a definition-use (sub)path in PATHS(P) with initial and final nodes 
DEF(v,m) and USE(v,n) such that no other node in the (sub)path is a defin¬ 
ing node of v [Jorgenson 1995]. 

The discrepancy between the views of time in SM-actions and DES-actions reflects 
the fact that the internal clock is continually updated by the hardware in the target system 
and is managed by the EDC policy implementation in the DES system. Every du-path with 
respect to the simulation-clock in an EDC DES-action is a dc-path whose defining node is 


umn 

time 

only 
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the clock-update-operation that preceded the action. Every usage node with respect to the 
internal clock in a SM-action on the target platform must be viewed as though there were 
an immediately preceding defining node for the internal clock in the program graph. 

This is not a problem for the DES-actions in the hypothetical model depicted in Fig. 
2.2. In that model, the clock update operation immediately precedes the single statement in 
the DES-action. However, it is a problem for HLL statement-level modelling because a sin¬ 
gle HLL statement can mask machine-code-level branching and preemption by higher pri¬ 
ority tasks. 

E. APPROACH 

This thesis avoids the problem caused by HLL statement-level modelling by em¬ 
ploying two related strategies. First, it delegates synchronization and timing operations to 
the software-architecture-domain and imposes policies that prohibit application-domain 
access to HLL statements for timing and synchronization. This allows the two implemen¬ 
tations of the software-architecture, the MPS and the SMPS, to have the same interface. 
Second, it prohibits application-domain access to the internal clock and simulation clock, 
and provides access to logical clocks instead. The logical clock is updated to the value of 
the internal clock just prior to SM-action invocation, so every du-path with respect to the 
internal clock is a dc-path whose defining node is the clock-update-operation that preceded 
the action. This assures that application-domain du-paths with respect to logical clocks are 
the same in the SM-actions as in the DES-actions. 
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III. THE MESSAGE-PASSING SUBSYSTEMS 


The first section of this chapter defines the terminology and graphical notation used 
to describe the MPS and SMPS. The second section describes the MPS and SMPS from a 
single application-level viewpoint. It also describes the sufficient conditions to achieve the 
goal of assuring that the application code running with the MPS exhibits the same behavior 
when running with the SMPS. The third section describes the SMPS model of MPS oper¬ 
ation in detail. 

A. TERMINOLOGY AND GRAPHICAL NOTATION 

There is no standard terminology to distinguish between conceptual entities of ob¬ 
ject-oriented analysis (OOA), object-oriented design (OOD), and object-oriented program¬ 
ming (OOP). This thesis follows SMM convention by using the term object to refer to a set 
of real-world things at the analysis level [Shlaer and Mellor 1992]. Individuals in the set 
are oh]Qct-instances. Design describes the approach to implementing the application spec¬ 
ified in the analysis. This thesis also employs the SMM convention of using the term class 
to refer to a set of entities at the design level [Shlaer and Mellor 1992]. Individuals in the 
set are referred to as class instances or class members. Every design class is implemented 
in a corresponding Java class. The term member-data is used to refer to the data associated 
with a class member. The term class-data is used to refer to data that is global to all instanc¬ 
es of a class. 

A number of OOA diagrams are presented in the appendices to facilitate the de¬ 
scriptions of system structure and function. These diagrams use OMT graphic notation 
[Rumbaugh 1991] but use SMM semantics [Shlaer and Mellor 1992]. 
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Objects in the object-information model (OIM) diagrams are depicted as boxes with 
two compartments. The top compartment contains the object name, and the bottom com¬ 
partment contains object attributes. Attributes with an asterisk are object identifiers. A sin¬ 
gle asterisk denotes a primary identifier and more than one asterisk denotes an auxiliary 
identifier. An attribute followed by where n is some number, is a relational attribute 

that formalizes a relationship. 

Object relationships are bidirectional and with the exception of subclass-superclass 
relationships, are depicted as connectors with arrowheads on each end. Clear and black ar¬ 
rowheads denote conditional and unconditional participants in relationships. Multiplicity is 
indicated by one or two arrowheads on an end of a relationship connector. One arrowhead 
indicates a single participant and two arrowheads indicates many participants. Relationship 
R7 in Fig. A-1 depicts a one-to-many conditional relationship that shows that each instance 
of Activator may be associated with zero or more instances of UnscheduledMessage. It also 
specifies that each instances of UncheduledMessage is always associated with an instance 
of Activator. 

The subclass-superclass relationship is depicted by a triangle and a set of connec¬ 
tors. The connectors emanating from the base of the triangle are attached to the subclasses. 
The connector emanating from the apex of the triangle is attached to the superclass. Rela¬ 
tionship R5 in Fig. A-1 depicts a subclass-superclass relationship. The UnscheduledMes¬ 
sage and ScheduledMessage objects are subclasses of MpsMessage. Each of these inherits 
the attributes of the ScheduledMessage superclass object. 

In state-model diagrams, boxes with rounded comers denote states and arrows de¬ 
note transitions. Transitions are labelled with the event label and event data may be listed 
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between parentheses next to the label. The state action is textually described in pseudocode 
contained in the state box. An event designation preceded by “%g” denotes event genera¬ 
tion. Event generation is equivalent to sending an event to the state-model of the destination 
object. The event destination can be inferred from the event name and the pseudocode. For 
example, the TH in the TH4 event in the “Getting Message” state shown in Fig. A-3 in¬ 
dicates that its destination is the thread state model. 

In OOA, delayed-event-delivery is the delivery of an event to an object’s state-mod¬ 
el at a specified time. This capability is represented in the SMM formalism by the prede¬ 
fined timer object. The TIMLset timer event has an event label, a delivery time, a 
destination object-instance, and a destination timer-instance. This event causes the timer- 
instance to send the named event at the specified time to the object-instance. The non-SMM 

event, TIM2:cancel, denotes delayed event-delivery cancellation. TIM7:fire denotes timer 
expiry for a SMM timer. 

B. APPLICATION-LEVEL VIEW OF THE MPS AND THE SMPS 
1. Overview 

The application-binary-code consistency (ABCC) requirement is that the same ap¬ 
plication binary-code execute in both the target execution-environment and in the simula¬ 
tion model. This investigation used an MPS-based software architecture that mapped one 
SM-action execution to one MPS message-activation. In the SMPS, each SM-action exe¬ 
cution must be implemented with one DES-action for the SMPS to be ABCC with the MPS. 
This section describes the MPS architecture design-properties that contribute to ABCC. 

The MPS and SMPS each comprise a fi-amework to implement OOA models. The 
frameworks support applications that depend on event-delivery for communication and 
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state-model execution for functionality. Each framework provides capabilities to imple¬ 
ment the concepts of active objects, passive objects, synchronous inter-object communica¬ 
tion, asynchronous communication, and delayed-event-delivery. 

In the MPS operational model, state-machine-execution threads, called activators, 
generate messages in SM-actions and transfer them to activator message-buffers or to the 
timer-thread delay-queue. The timer-thread transfers messages in the delay-queue to the 
appropriate activator message-buffers at the scheduled delivery time for each message. An 
activator repeatedly acquires the next message from its buffer and executes the appropriate 
SM-action. However, an activator will wait for a message if none are available. 

The MPS and SMPS define two superclasses, MpsObject and MpsMessage, both 
shown in Fig. A-1 and Fig. A-2, that provide many of the interfaces needed to implement 
the information structure and system dynamics specified in an OOA model. Application de¬ 
velopers produce specializations of MpsObject and MpsMessage that extend their proper¬ 
ties and inherit their interfaces. Specializations of MpsObject contain member-data that 
correspond to object-attributes defined in the application OIM. Such specializations also 
contain methods that implement state-model actions for active objects in an application 
OOA. Direct access to member-data or ge/-methods and jjwt-methods implements synchro¬ 
nous inter-object communication specified by accessor-processes in state-model ADFDs. 

The activator-objects (AO) in an MPS-based application are the activators, MpsOb- 
jects, and MpsMessages shown in Fig. A-1 and Fig. A-2. Execution priority forms a parti¬ 
tion on the set of AO in MPS-based applications. The partition is indicated by relationship 
R1 in Fig. A-1 and Fig. A-2. All MpsObject and MpsMessage methods are restricted to ex¬ 
ecute in the context of the activator with the priority that defines their equivalence class. 
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AOp, with two exceptions. The two exceptions are the methods that implement event-gen¬ 
eration and delayed event-delivery. Instances of each MpsMessage subclass may only be 
sent to the MpsObject subclass, or to instances of the subclass indicated by relationship R4. 

Specializations of MpsMessage implement events specified in OOA state-models. 
The MpsObject superclass defines a send-mtihod that takes a parameter of type Unsched- 
uledMssage to implement event-generation. UnscheduledMessage-instances are placed in 
the activator message-buffer depicted in relationship R7. Event data are implemented as 
MpsMessage member-data. 

The timer, the delay-queue, the MpsObject schedule-m&ihod, and the Sched- 
uledMessage subclass of MpsMessage provide the OOA delayed-event-delivery capabili¬ 
ty. Relationship R6 in Fig. A-1 and Fig. A-2 depicts the delay-queue and its relationship to 
the timer. The schedule-method has two arguments, an activation-time and an Sched- 
uledMessage-instance. When a schedule-method is invoked, it assigns the activation-time 
to the ScheduledMessage-instance and inserts the instance into the delay-queue. The timer 
repeatedly gets the ScheduledMessage-instance with the earliest activation-time, waits un¬ 
til that time is reached, and then transfers the MpsMessage-instance to the appropriate ac¬ 
tivator message-buffer. 

The MpsMessage class has an abstract activate-meihod that must be overridden 
with a concrete implementation by each concrete MpsMessage subclass. Activate-method 
execution must determine the next state for the destination MpsObject-instance and execute 
the SM-action on its behalf Each activator serially executes SM-actions on behalf of its 
MpsObject-instances by executing activate-methods. 
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2. Policies and Properties 

Clarke defines a program P with a set of variables V [Clarke et al. 1989]. An acti- 
vate-method A in program P with control flow graph G(A) == (N, E, n^, nf) has initial-state 
Si in which (veSj) (veV a nsN a USE(v,n)). Activate-method A has a final state, Sf, 
in which (v€ Sf) o (ve V a neN a DEF(v,n)). An activate-method that generates the same 
final state in the MPS and SMPS when given the same initial state has activate-execution 
(AE) predictability. 

An SMPS program that executes its activate-methods in the same order in the 
SMPS as in the MPS has activate-invocation-order (AIO) consistency. An MPS-based ap¬ 
plication will have the same timing and synchronization properties and will produce the 
same results in the SMPS as in the MPS if the activate-methods are AE-predictable and the 
SMPS program is AlO-consistent. 

Let V be the set of variables v in program P and let denote the happens before 
relation [Lamport 1978] applied to the execution-order of statements and statement frag¬ 
ments in P. An MPS-based program P will have AE-predictability if for all of P’s execu¬ 
tions and for any two non-unique activate-methods X and Y in P with G(X) = (M, G, mg, 
mf) and G(Y) = (L, F, Ij, If), DEF(v,l) and USE(v,m) => (m^lj a lf->ms) v (lf->m5 a 

mf-»ls). 

The MPS and SMPS data-access policy is that for any two MpsObject-instances, 
01p€ AOp and 02q€ AOq, p=q => synchronous data exchange is allowed, p^^q => synchro¬ 
nous data exchange is not allowed and must be performed by message passing. The serial 
nature of activator state-machine execution and the data-access policy assure that each 
MpsMessage-instance in AOp will have exclusive access to all of the member-data in AOp 
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for the duration of its activate-method. The data-access policy confers AE-predictability on 
MPS-based applications. 

An activate-method that accesses the system clock will violate the data-access pol¬ 
icy and may undermine AE-predictability because the value of the system clock will 
change independently of activate-method execution. This problem is avoided by assigning 
an EventClock-msXzncQ to each activator. The EventClock-msXance is updated to system¬ 
time just prior to each activate-method execution and remains fixed for its duration. This is 
depicted by relationships R9 in Fig. A-1 and Fig. A-2. The MpsObject class defines a mil- 
// 5 -method that returns the time of the associated EventClock-instance via relationships R2 
and R9. 

The MPS and SMPS have a synchronization policy with two rules. First, the OOA 
state-models for an application must represent all synchronization requirements. Second, 
all required synchronization must be implemented by message-passing. This policy prohib¬ 
its application-level use of HLL statements for timing and synchronization. That would 
cause variation in execution-time that would not be modelled in the SMPS. An activate- 
method has path execution-time (PET) consistency if the variation in its MPS execution¬ 
time only results from preemption by another MPS thread or fi-om executing different sub¬ 
paths in G(A). PET-consistent activate-method execution-time depends only on its initial 
state, the platform performance, and its preemption time. 

The SMPS model assumes PET-consistency. The potential AlO-consistency of an 
SMPS model of an AE-predictable and PET-consistent MPS-application depends on the fi¬ 
delity of underlying run-time system model, the MPS-overhead model, and the activate- 
method execution-time model. Model inaccuracy will degrade AlO-consistency. 


25 


MpsMessage send-times in the MPS and SMPS will be different if messages are al¬ 
lowed to be sent at any arbitrary time during activate-method execution. The time that an 
MpsMessage-instance is sent affects the time that its activate-method is invoked. An SMPS 
application cannot be AlO-consistent if message send-times are different in the MPS and 
SMPS. As can be seen in Fig. 3.1, this results from the different views of time presented by 
the MPS system clock and the SMPS EDC. 

SMPS and MPS message send-times must be constrained to occur at the SM-action 
end-time. This requirement is very cumbersome for programmers. In order to avoid this, 
the 5e«i:/-method and schedule-mQthodi only place messages in temporary storage. The ac¬ 
tivator transfers the messages from temporary storage to the appropriate buffers upon re¬ 
turning from the activate-method. The SMPS will have accoimted for activate-method cpu- 
time consumption and preemption-time by that point. The message transfer takes place in 
the Transferring Msgs action of the activator state-model shown in Fig. A-4. 

An SMPS version of an MPS-based application can have the same timing and syn¬ 
chronization properties and can generate the same results if the activate-methods have AE- 
predictability and the SMPS version has AlO-consistency. An application that complies 
with the data-access and synchronization policies will have AE-predictable activate-meth¬ 
ods. An application must have PET-consistent activate-methods and PET-consistent MPS- 
infrastructure code to be AlO-consistent. However, an SMPS-application must incorporate 
an adequate platform-performance model into all activate-methods and into the SMPS in¬ 
frastructure to be AlO-consistent. 
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c. 


THE SMPS MODEL OF THE MPS 


In the MPS operational model, MpsMessage-instances are generated in MpsObject 
SM-actions and are either transferred to activator message-buffers or to the delay-queue. 
The timer transfers messages in the delay-queue to the appropriate activator message-buff¬ 
ers at the message activation-times. Activators acquire messages from their message-buff¬ 
ers and invoke their activate-methods. 

The SMPS must also account for preemption in the MPS to support AlO-consisten- 
cy. The model of the Java run-time executive (RTE) is depicted in the interactions between 
the RTE state-model shown in Fig. A-5 and the thread state-model shown in Fig. A-6. The 
model of the implementation of the activator-thread rwn-method is depicted in the interac¬ 
tions between the activator state-model shown in Fig. A-5 and the thread state-model 
shown in Fig. A-6. The model of the implementation of the timer-thread run-method is de¬ 
picted in the interactions between the timer state-model shown in Fig. A-3 and the thread 
state-model shown in Fig. A-6. The next three subsections describe the SMPS model of the 
Java implementations of the MPS activator and timer. 

1. Thread Context Switching 

The MPS activator and the MPS timer behavioral models are split into a generic 
thread state-model and a role-specific state-model. The thread state-model implements the 
model of context switching. Dynamic priorities are used to prevent preemption during cer¬ 
tain portions of the life-cycles of activators and timers. This reduces the number of states 
in which context switching can occur. 

Context switching is modelled in the thread state-model as a three-state transition 
from Ready to Switching Context to Running as shown in Fig. A-6. When the RTE sends 
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TH2 to a thread in the Ready state, the thread moves to the Switching Context state. When 
the thread arrives in that state, it schedules another TH2 event to be delivered to itself when 
the context switching time expires. The TH2 transition from Switching Context to Running 
invokes an SM action to send TH2 to its client thread subclass state-model. Context switch¬ 
es in the timer and activator classes are denoted by the TH2 transition in Fig. A-3 and Fig. 
A-4. 

2. The Activator 

In order to achieve AlOconsistent, the SMPS model must account for CPU-time 
consumed by activate-method execution, activator-preemption, MPS overhead, and thread 
context-switching. 

The synchronized modifier is used to implement mutual exclusion in Java. Each 
Java class-instance has a lock [Gosling et al. 1996]. A thread that invokes an instance’s syn¬ 
chronized method implicitly requests the instance’s lock. If the lock is owned by another 



Figure 3.1. Java Wait-Notify Interaction 
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thread, the requesting thread is blocked until the lock becomes available to it. The MPS 
uses synchronized methods to synchronize MpsMessage-acquisition and transfer. 

The wait and notify methods are used to implement condition synchronization in 
Java. A thread that calls a instance’s wait-method will block and be added to the instance’s 
wait-set until another thread invokes the instance’s notify-method [Gosling et al. 1996]. 
Notify will select one of the waiting threads, remove it from the wait-set, and make it ready 
to run. The selected thread will throw InterruptedException when it runs again. 

The sample code in Fig. 3.1 depicts a basic Java wait-notify interaction in a buffer 
implementation. A consumer-thread that calls the ^e^method shown in Fig. 3.1 will block 
at the wait statement if the list is empty. The list will be non-empty after a producer-thread 
calls put. The put-operation calls notify, causing InterruptedException to be thrown to one 
of the consumer-threads waiting for the buffer’s lock. The interrupted consumer will exit 
the catch clause after the producer-thread releases the lock. The consumer-thread will make 
a transition from the ready state to the running state. 

a. Activator Creation and Start-up 

Role-specific behavior is acquired by a thread by overriding the thread’s 
predefined rw«-method. A thread’s run-method may execute only after its start-mdhod has 
been invoked. 

An SMPS activator-instance is created in the Created state when a thread 
invokes the activator’s constructor. Figures A-4 and 3.2 show the THl-transition from Cre¬ 
ated to Starting and Fig. A-4 shows the SM-action for the Starting state. In Starting, the 
activator sends THl to the activator-thread’s state-model causing a transition to the Ready 
state. The RTE makes the thread the currently running thread by sending TH2 to its state- 
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model. This simulates Java^tort-method execution and causes the transition from the Start¬ 
ing state to the Getting Message state shown in Fig. 3.2 and Fig. A-4. 

The SMPS model of an MPS activator primarily models its run-method. The 
activator run-method repeatedly acquires a message from its message-buffer, updates its 
EventClock-instance, executes the message activate-method, and transfers the generated 
messages from temporary storage to their target buffers. Figure 3.3 shows an abridged ver¬ 
sion of the source code for the MPS activator run-method. 
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b. Non-Blocking Message-Acquisition 

Line four in Fig. 3.3 shows an example of MpsMessage-acquisition. Figure 
3.2 depicts MpsMessage-acquisition in a scenario with an initially non-empty message- 
buffer. An MPS activator that invokes get for a non-empty message-buffer will not block. 
This is modelled by the else branch in the Getting Message action shown in Fig. A-4. 

An SMPS activator must compute the CPU-time consumed by the Event- 
Clock update operation and the operation that removes the message at the front of its mes¬ 
sage-buffer. It must also schedule itself to complete its message-acquisition after that 
amount of time has elapsed. This is shown by the transition labelled TH3 that goes from the 
Getting Message state to the Activate state shown in Fig. A-4. 

Message-acquisition CPU-time consumption is simulated by sending TIMl 
to an SMM timer-instance. Timer expiry is represented by the second occurrence of TIM7 
in Fig. 3.5. The timer sends TH3 to the activator when the correct amount of CPU-time 
elapses. 

Priority inversion is the condition in which a higher priority thread is 


1 

public void run() { 


2 

setPriority(MPS.MAX 

PRIORITY); 

3 

do { 


4 

MpsMessage msg = 

tbuff[id].get (); 

5 

if (msg == null) 

{ 

6 

break; 


7 

} 


8 

eclock.update() ; 


9 

setPriority(pri) ; 


10 

msg.activate() ; 


11 

setPriority(MPS.MAX PRIORITY); 

12 

transfer(); 


13 

} while (forever); 


14 

} 



Figure 3.3. MPS Activator Run-Method 
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blocked by a lower priority thread. Consider a Java program with three threads T1, T2, and 
T3 listed in ascending priority. Assume that they use the buffer in Fig. 3.1 and that it is in¬ 
itially non-empty. The following sequence of events will cause priority inversion because 
T1 will be blocked by T2’s execution. 

• T1 invokes buffer.get and acquires the lock 

• T2 and T3 become ready to run when T1 is at line seven in Fig. 3.1 

• T3 preempts T1 

• T3 invokes buffer .put, requests the lock, and is added to buffer’s wait 
set 

• T2 runs 

Activators raise their priority to the maximum in the Starting state or the 
Transferring Msgs state to prevent preemption during message-acquisition and transfer. 
This also avoids activator-buffer and delay-queue lock-contention and precludes the neces¬ 
sity to model lock-contention in the SMPS. It also avoids blocking-delay due to priority in¬ 
version. 

c. Blocking and Unblocking in Message-acquisition 

Figure 3.4 depicts a scenario with two activators, A1 and A2. The scenario 
begins at the point in which A2 begins to execute the SM-action of the Getting Message 
state. The empty message-buffer condition will cause A2 to execute the //-branch in the 
Getting Message SM-action shown in Fig. A-4 and to send TH4 to itself. TH4 will cause it 
to transition to the Waiting for Message state depicted in Fig. 3.4 and Fig. A-4. The self- 
directed TH4 event simulates the effect of executing a wait-method such as the one depict¬ 
ed on line seven of Fig. 3.1. 
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The following sequence of events models the process by which an activator 


may become blocked at a wait statement like the one depicted at line eight in Fig. 3.1. In 
the Waiting for Message SM-action, A2 sends TH4 to its thread state-model, causing the 


thread to enter the Blocked state. In the Blocked SM-action, the thread sends TH3 to A2 and 


Activatorl Thread 1 Activator2 Thread2 RTE SM Timer 



Figure 3.4. 

State-Event Chart for Message Acquisition with an Initially Empty 

Message-Buffer 
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sends RTE3 to the RTE. RTE3 causes the RTE to enter the Blocking state and it may exe¬ 
cute a context switch. 


After A2 has become blocked, A1 sends THl to A2’s thread from the Trans¬ 
ferring Msgs SM-action. This models the effect of invoking notif; in a put operation as 
shown at line 16 of Fig. 3.1. THl causes A2’s thread to transition from Blocked to Ready 
and to send THl to A2, which is ignored. When the RTE moves A2’s thread from Ready 
to Running, the thread sends TH2 to A2, causing it to go from Waiting for Message to Get¬ 
ting Message. A2 continues from that point as described in the discussion for non-blocking 
message-acquisition. 

d. Activate-Method Execution and Preemption 

Line eight in Fig. 3.3 depicts an activator that acquires a message and up¬ 
dates its EventClock-instance to the current system time. The activator reduces its priority 
after it updates the EventClock and then invokes its activate-method. The activate-method 
will only modify the values of attributes in the same AOp and it may place generated-events 
in temporary storage. However, no simulation-time will elapse during activate-method ex¬ 
ecution in the SMPS. 

Activate-methods must be invoked at the same time in the SMPS as they 
would have been in the MPS in order to be AlO-consistent. Activate-method completion¬ 
time is the time at which an activate-method completes in the MPS. The SMPS models this 
as the sum of activate-method start-time plus the CPU-time consumed by the activate- 
method plus its preemption-time plus the context-switching time associated with preemp¬ 
tion. 
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The activator must delay the occurrence of two operations until activate- 
method completion-time to achieve AlO-consistency. First, it must delay the transfer of the 
messages from temporary storage to message-buffers. Second, it must delay the start of the 
next activate-method. 

The activator-class defines an add2ActionTime-me\hod that adds an incre¬ 
ment of simulation-time to the value of an internal action-time variable. In the SMPS, this 
variable’s value is reset prior to each activate-method invocation. 

The activate-method uses addlActionTime to dynamically accumulate acti¬ 
vate-method timing information during execution. The action-time variable should contain 
the amount of CPU-time that would be consumed during MPS-based activate-method ex¬ 
ecution in the target environment. Action-time is unused in the MPS. However; it is used 
by the SMPS to compute activate-method completion-time. 

An activator executes the activate-method in the SM-action of the Activate 
state shown in Fig. A-4. The activator transitions to Activating after completing the acti¬ 
vate-method. The transitions between Activating and Preempted simulate the passage of 
activate-method execution-time and preemption-time. 

Preemption can only occur in the MPS during activate-method execution 
because message-acquisition and message-transfer are performed at elevated priorities. 
Preemption only occurs when a timer’s timeout expires and the timer transfers a message 
to an activator-buffer owned by a waiting activator. The message-transfer unblocks the 
waiting activator as described in the discussion on blocking message-acquisition. The acti¬ 
vator will also continue processing until it reaches the Activating state. At this point, the 
activator will have executed its activate-method without affecting any objects in other 
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AOpS due to AE-predictability constraints. If the activator lowers it priority to a lower pri¬ 
ority than the preempted activator’s priority, the RTE will perform a context-switch and re¬ 
store the preempted activator to the running state. 

The amount of time elapsed during preemption will be equal to the sum of 
the timer message-transfer time and the activator message-acquisition time. Although its 
activate-method will have executed, activate-method execution-time does not affect the 
simulation clock at that point. 

The state-event chart shown in Fig. 3.5 shows the sequence of events and 
state transitions involved in preempting activator A1 in the Activating state. Initially, the 
SMPS timer will have scheduled an event-delivery by setting the SMM timer to expire at a 
later time. This timer expiry is depicted by the appearance of TIM7 in the upper part of the 
SMM timeline in Fig. 3.5. The SMM timer sends THl to the SMPS timer-thread when the 
SMM timer expires. The SMPS timer-thread interrupts the SMPS timer and the SMPS tim¬ 
er proceeds through a succession of state transitions causing it to send RTEl to the RTE. 
The RTE compares Al’s priority and the timer’s priority and sends THl to the A1-thread 
and TH2 to timer-thread because the timer-thread has a higher priority than Al. The Al- 
thread transitions to the Ready state and sends THl to A1. A1 transitions to the Preempted 
state when it receives TH1. 

The simulation clock is updated twice during this series of interactions. 
First, it is updated at the time of timer expiry depicted by the appearance of TIM7 in the 
upper part of the SMM timeline shown in Fig. 3.5. It is updated again at the second appear¬ 
ance of TIM7 that represents the context-svidtching time of the timer-thread when it transi¬ 
tions from CtxToRunningl to Getting Message. Al computes Tremain, the amount of 
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activate-method execution time remaining, by subtracting its last activation start-time from 
the current simulation-time. When the RTE causes it to transition to the Activating state 
again, it will recompute its activate-method completion-time as the sum of the then-current 
simulation-time plus Tremain. 
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Figure 3.5. State-Event Chart for Preemption 
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3. 


The Timer 


Activators remove the message from the buffer in the Getting Message state and 
transfer messages from the buffer in the Transfer Msg state. However, the timer does not 
remove the message from the delay-queue until it reaches the Transfer Msg state because 
a message with an earlier transfer time can be inserted into the delay queue while the timer 
is in the Timeout state. The timer is never preempted because it always executes at the 
thread message-transfer and message-acquisition priority. 

The delay-queue maintains a list of ScheduledMessage-instances that are sorted by 
activation-time. Figure A-3 shows that the timer transitions to the Timeout state when it 
identifies the message at the front of the delay-queue. In the Timeout SM-action, the timer 
sends TH3 to its thread and schedules THl to be sent to its thread after the timeout period 
elapses. These events cause the timer-thread to transition immediately to Blocked and later 
to Ready when the timeout elapses. Figure 3.5 shows that the SMM timer sends THl to the 
SMPS timer-thread. That causes the SMPS timer-thread to transition to the Ready state. 
The timer-thread sends THl to the timer, which is ignored. 

The delay-queue put-method compares the activation-time of the new MpsMessage 
argument against the timer’s current-message activation-time. If the new message activa¬ 
tion-time is earlier, then it pushes the current-message and the new message argument onto 
the delay-queue. It then sets the current-message to null and sends THl to the timer’s 
thread. This causes the timer to process the earlier message. 

D. SUMMARY 

The application-binary-code consistency (ABCC) requirement is that the same ap¬ 
plication binary-code execute in both the target execution-environment and in the simula- 
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tion model. The investigation used two implementations of a message-passing architecture, 
the MPS and the SMPS, that implement state-machine-execution engines to support appli¬ 
cation-binary-code consistency (ABCC). 

Several MPS design-properties contribute to ABCC. First, each SM-action execu¬ 
tion was implemented with a single message-activation. In the SMPS, each SM-action ex¬ 
ecution was implemented with one DES-action. Second, the MPS and SMPS message- 
activation methods must generate the same final state, given the same initial state. Third, 
an MPS-based program must execute its SM-action methods at the same time in the SMPS 
as in the MPS. Finally, data access and synchronization policies must assure mutually ex¬ 
clusive data access. 

An MPS-based application can be ABCC for an MPS and SMPS that have these de¬ 
sign properties if the variations in its sub-path execution-times only results from preemp¬ 
tion by another MPS thread. The SMPS sub-path execution times are obtained from an 
MPS platform performance model (MPPM). However, if execution conditions are impos¬ 
sible to specify and control, then the MPPM will be invalid and ABCC cannot be achieved. 
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IV. MPS PLATFORM PERFORMANCE MODELLING 


The first section of this chapter discusses MPS platform performance model 
(MPPM) requirements for validity. The second section provides an overview of dual-loop 
(DL) testing, and describes DL test structure principles, design considerations, and side ef¬ 
fects in DL testing. The third section describes MPPM development in the investigation 
used in this thesis. The fourth section describes how the MPPM was incorporated into the 
SMPS. The fifth section provides conclusions on MPS platform performance modelling. 

A. MPPM REQUIREMENTS 

The validity of the SMPS and its associated MPS-based application depends par¬ 
tially on the fidelity of the MPPM. An MPS platform performance model (MPPM) is a set 
of functions that return MPS execution-time estimates (ETE) that model the execution- 
times of MPS module sub-paths under MPS-application execution conditions. A Java com¬ 
pilation configuration comprises the Java compiler and the compiler options used to com¬ 
pile the MPS and MPS-applications. An MPS execution platform consists of a Java virtual 
machine (JVM), an operating system, and a hardware platform. MPS-application execution 
conditions are defined by a Java compilation configuration, an MPS execution platform 
configuration, and a system loading specification for a particular MPS-application execu¬ 
tion. 

An SMPS execution has strict MPPM-validity if the MPPM functions return MPS 
ETEs that are the same as the corresponding MPS sub-path execution-times at the same 
time relative to the program execution start time. This definition does not require or assume 
PET-consistency. An SMPS execution that has strict MPPM-validity is AlO-consistent 
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with an MPS program execution and can be used to reproduce MPS application behavior 
in a run-time environment that is free of the probe effect. 

The MPS execution platform used for the investigation presented in this thesis was 
a 200 MHz Pentium PRO computer with a 256 KB on-chip cache and 96 MB of 60 ns RAM 
running under Windows NT 4.0 and the Java Development Kit (JDK) version 1.1.6. If MPS 
execution conditions are impossible to specify and control for such a configuration then a 
strictly valid MPPM cannot be developed. In addition, MPS applications executing on an 
unpredictable platform are not PET-consistent. This raises the question of whether an 
MPPM can be developed that is sufficiently predictable to support useful software testing 
in contrast to providing strictly reproducible behavior. An MPPM is useful if the sum of the 
effort devoted to its development and to testing a set of control-flow paths in the SMPS is 
less than the effort required to test the same paths in the MPS. MPPM usefulness is related 
to the difficulty of testing the real system. 

A partial MPPM was developed for this configuration that consists primarily of 
Java language feature ETEs. This MPPM contains of a set of mappings of feature-names to 
ETEs and does not account for performance variations due to system loading or properties 
of the execution platform. 

B. DUAL-LOOP (DL) TESTING OVERVIEW 

1. DL Test Structure 

The DL approach is based on the assumption (i.e., the DL-assumption) that the dif¬ 
ference in execution-times of two segments of code that are identical except for the pres¬ 
ence of a feature-of-interest is equal to the execution-time of the feature-of-interest. A dual¬ 
loop test generates an ETE of a feature-of-interest by comparing the execution-times of an 
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experimental loop and a control loop. The two loops are identical except that the experi¬ 
mental loop contains the feature-of-interest. For control loop execution-time, T^., and ex¬ 
perimental loop execution-time, T^, the feature-of-interest execution-time, 3^ is computed 
as Tf = Tg - Tg [Pollack and Campbell, 1990]. 

Let Mgi and M^j be the measured execution-times of N iterations of the experimental 
loop and N iterations of the control loop. Let il^be the measured feature execution-time 
computed as Mj-= {Mgj - M^/)/N. The basic clock resolution of the clock-function, x, is usu¬ 
ally too coarse to permit Mgj and Mgj to be used as estimates of and 7], when iV=l. The 
time measurement uncertainty is x for Mgi and for Mgi, so NMj- 2x < NTf< NMf+ 2x. The 
value of required to confine the measurement uncertainty to a fraction,/?, of NMj-, is given 
hy N> li/ipMj) [Pollack and Campbell, 1990]. 

Altman examined the DL-assumption after measuring negative ETEs for some DL 
benchmarks written in Ada [Altman, 1987]. He attributed some of the main sources of dis¬ 
tortion in test results as being due to design or implementation errors and interference from 
side-effects. Design and implementation errors can be addressed. However side-effects are 
due to external factors that can be impractical or impossible to precisely quantify and con¬ 
trol. 

2. DL Test Design Considerations 

An in-depth knowledge of the target programming language may be required to 
avoid DL test design errors and to avoid compromising MPPM fidelity. An MPS applica¬ 
tion that uses many language features that differ in subtle ways can necessitate a large test 
suite to generate an MPPM for an MPS application. For example, consider the problem of 
measuring Java calling overhead for methods with various numbers of arguments and var- 
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ious argument types. A conservative assumption is that any different signature type has po¬ 
tentially different performance implications. 

Table 1 shows an example of variability in Java method signature types based on 
the conservative assumption. The top row contains the variability category for each col¬ 
umn. The last row contains the number of values for each category. The intermediate rows 
display the names of the values in the category or an indication of the presence or absence 
of a value in the category. Some of the factors pertain to the value or presence of a throws 
clause, a synchronized modifier, a static modifier, access modifier, or a final modifier. The 
others pertain to the method return type and the argument types. 

The number of unordered combinations of argument types that can be constructed 
from three arguments and seven argument types is (A:+«-l)!/(?7-l)!A:! where n is one more 
than the number of data types and k is the number of arguments. This is analogous to de¬ 
termining the number of different colorings of k golf balls with n colors [Anderson, 1974]. 
The extra argument corresponds to the void argument or the absence of an argument. The 
number of different unordered combinations is 120 (i.e., (8+3-1)! / (8-1)1*31). The number 
of different signatures is 30720. This value is the product of the number of factors in each 
category multiplied by the number of different combinations of arguments (i.e., 
2*2*2*2*4*8*120). 

Not every kind of method signature variation affects performance. Some of the Java 
method modifiers probably only affect compile-time consistency checks. Table 2 shows an 
optimistic interpretation of variability in Java method signature types. The categories in ta¬ 
ble 2 are partially based on properties in generated code that are assumed to affect perform¬ 
ance. For example, methods that have the static, final, or private modifiers or that are 
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declared in a class that has the final or private modifiers may be able to be inlined. The table 
also assumes that argument size rather than argument type is relevant to method-calling 
overhead execution-time. 
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Table 4.1: Conservative Interpretation of Variability in Java Method Signature Types 


The number of argument signature types that can be constructed from three argu¬ 
ments and four data types is 35 (i.e., (5+3-1)! / (5-1)1*31). The number of different signa¬ 
ture types based on the optimistic assumption is 140. 
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Table 4.2; Optimistic Interpretation of Variability in Java Method Signature Types 
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Table 4.2: Optimistic Interpretation of Variability in Java Method Signature Types 

3. Side Effects 

The MPS compilation and execution environment contains several possible sources 
of instability for MPS sub-path execution-time. These sources of instability can be attrib¬ 
uted to the JDK 1.1.6 JVM, Windows NT 4.0, or the Pentium PRO hardware platform. The 
JDK 1.1.6 JVM contains a bytecode interpreter and a Just-in-time (JIT) compiler. The JIT 
performs adaptive optimization at run-time by determining the methods that are called most 
often and by generating machine code for them on-the-fly [Yellin, 1996]. This can lead to 
variations in sub-path execution-times in the absence of other factors. The JVM also per¬ 
forms garbage collection at unpredictable times. 

Windows NT 4.0 is a preemptive multi-tasking operating system that performs var¬ 
ious operating system services in independent execution threads. These can preempt an 
MPS application and result in variations in sub-path execution-time. The Pentium PRO 
processor has a high-speed memory cache. Variations in the sequence of memory fetches 
can affect the percentage of cache hits and lead to a differences in sub-path execution- 
times. 

C. MPPM DEVELOPMENT 

1. The MPPM of the Passage of Time 

It is essential to obtain an estimate of x, T^j., because x is integral to the application- 
level view of the passage of time. At any time, T, the value returned by the Java clock func- 
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tion, system. currentTimeMillis, will be U_(r/x)jTj, where L J is the floor function. The value 
of T is also required to compute the number of iterations to execute the control and experi¬ 
mental loops that are used measure the execution-time of a particular code segment. The 
value returned from system. currentTimeMillis was assigned to each element of a large ar¬ 
ray. The sample values consisting of the non-zero differences between successive array el¬ 
ements were counted and summed to obtain T^f. This process was repeated ten times and 
the average of the samples, T^r, was computed to be approximately 15.625 milliseconds 
(ms). The source code for the test program is shown in Fig. B-1. 

Each MPS and SMPS activator updates its event-clock with the current value of the 
SystemClock at the beginning of each action as shown in Fig. A-3 and Fig. A-4. The Sys- 
temClock function was implemented in the MPS by calling the Java System.current- 
TimeMillis method from the MpsRealClock.millis method. In the SMPS, the 
MpsKealClockmillis method models the Java System.currentTimeMillis method. This pro¬ 
vides a more accurate application-level view of current-time than simply returning the val¬ 
ue of the EDC-clock. The SMPS MpsKealClockmillis source code is shown in Fig. B-2. 

Figure B-3 shows the source code for the test to determine the Java wait-method res¬ 
olution. The test performed 30 invocations of the wazV-method for each value in the range 
of one to 50 milliseconds. Figure 4.1 shows the results of the test. Requested delay is shown 
on the abscissa and measured delay is shown on the ordinate. In each case, the measured 
delay resolution is T^p but the average measured delay is close to the requested value. The 
results do not validate a particular model of wa/V-method resolution. However, they do not 
contradict the optimistic assumption that wa/Y-method resolution is high relative to the 
clock function resolution.The SMPS timer implementation design is based on the optimis- 
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Requested Delay (ms) 


Figure 4.1. Java Wait Statement Resolution for a 200 MHz Pentium Pro with 
96 MB 60 ns DRAM and 256K On-Chip Cache 

tic assumption and uses the EDC-clock rather than the SMPS MpsRealClock to compute 
delay-times for delayed-event-delivery. However, the application-view of delayed-event- 
delivery duration can only be accessed using MpsRealClock. millis so its view of the clock 
function resolution is still T^r. 


D. GENERAL DL TEST DESIGN AND IMPLEMENTATION 

The majority of the DL tests were implemented as type extensions of the abstract 
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FeatureTest class. FeatureTest declares the following four abstract methods: initialize, cal¬ 
ibrate, and execute. Each concrete subclass must implement those three methods. Initialize 
initializes the test state. Calibrate executes multiple iterations of a loop that exercises the 
control and experimental loops times per iteration, and doubles N for each successive it¬ 
eration. It calculates Tf fox a feature and completes when Tf> (21 ^.^p, where /7=0.01. Exe¬ 
cute re-computes 7^ at the calibrated value for N, M times, where M, is the number of test 
repetitions. Initially, Mwas set at 29, so a total of 30 repetitions of each test was performed. 
However, M was eventually reset to zero because there was so little variation between suc¬ 
cessive runs. 

Figure 4.2 shows the test results and output of a method calling overhead test, pro¬ 
gram smsipubvSpMf. Program smsipubvSpMf measures the calling-overhead of a method 
with the public, static, and synchronized modifiers. The method also has three integer ar¬ 
guments and no return value. Figure 4.2 shows that N ranged from 2^^ to 2^' during the 
calibration portion of the test. The variation in Mf was less than 0.4% of the mean for the 
five runs and the average value for Mf was approximately 2.12 microseconds. 

E. INCORPORATING THE MPPM INTO THE SMPS 

The CpuCharger interface requires an implementation to provide methods that add 
a quantity of time to an accumulator, clear an accumulator, and return the accumulated val¬ 
ue. The SMPS activator and timer implement the CpuCharger interface and use CpuCha¬ 
rger methods to maintain a record of estimated CPU-time use. The activator defines 
an addlActionTime-method that adds an increment of simulation-time to the value of an 
internal action-time variable. This is exported to MPS-applications and provides a way for 
MPS applications to communicate activate-method CPU-time consumption to activators. 
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The ETEs obtained from the DL tests were stored as a set of mappings of DL test- 
names to ETEs. Java statements and ETE names were embedded in special comments in 
the SMPS source code. Figure B-4 shows the SMPS MpsFifo.append method with embed¬ 
ded Java statements and ETE-names. The source was submitted to a processor that strips 
out the special comments and replaces the ETE-names with their values. Figure B-5 shows 
the result of processing MpsFifo.append. 

Figure B-5 shows that Vappend_lmf covAQ.\xiS the sum of the ETEs for the append- 
method calling overhead, the //^statement evaluation, and the statements in the first branch 
of the {/^statement. Vappend_2mfconteims the sum of the ETEs for the append-mQiiiodL call¬ 
ing overhead, the //^statement evaluation, and the statements in the second branch of the if- 
statement. Each branch invokes cc. charge which adds the DD-path ETE to the CPU-time 
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Figure 4.2. Output from the smsipubv3pMfD\xd\-\ooTp Test 
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accumulator for the SMPS thread. 


Language features such as conditional evaluation and self-modifying expressions 
should be avoided unless the DD-path execution can be known ahead of time, since they 
contain more than one DD-path in a single statement. 

F. CONCLUSIONS 

A partial MPPM was developed for the target platform using the dual-loop ap¬ 
proach to measuring execution-time. The validity of an MPPM developed using the DL test 
approach on a predictable platform is related to the validity of the DL assumption. A large 
number of DL tests may be required to accurately reflect DD-path execution-times due to 
programming language subtleties. Good DL test design requires an in-depth knowledge of 
the target programming language. 

Factors such as the JDK 1.1.6 just-in-time compiler, the Windows NT 4.0 preemp¬ 
tive multi-tasking operating system, and the Pentium PRO high-speed cache are sources of 
unpredictably in the MPS execution platform. If MPS execution platform performance is 
unpredictable then MPS-application behavior cannot be precisely reproduced using the 
SMPS. However, an MPPM can be useful if its reduces the effort to test control-paths that 
are difficult to reproduce in real systems. 
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V. DEMONSTRATION PROGRAMS 


This chapter is concerned with demonstrating and evaluating the synchronization 
and timing properties of MPS-based applications running with the SMPS. Two MPS-based 
programs were developed that illustrate well-understood synchronization and timing prin¬ 
ciples. The first is an MPS-based solution to the “Dining Philosophers” problem [Dijkstra, 
1971] that was developed to study SMPS timing and synchronization. The second is an 
MPS-based program with Rate Monotonic Scheduling (RMS) priority assignments and ar¬ 
tificial workloads [Sha and Goodenough, 1990]. This program was developed to study 
SMPS timing and the model of a preemptive multi-threaded run-time system. 

The first section describes the “Dining Philosophers” problem and the MPS-based 
solution implemented with the uniprocessor-based SMPS. It also compares timing and syn¬ 
chronization in the actual program to timing and synchronization in the ideal case. The sec¬ 
ond section describes the RMS program and compares timing and preemption in the actual 
program to timing and preemption in the ideal case. The third section presents the conclu¬ 
sions and describes the implications for the distributed systems question. 

A. DINING PHILOSOPHERS (DP) 

In this problem, five philosophers are seated at a round table. Each philosopher has 
a plate, and between each pair of plates is a chopstick. A philosopher must acquire the chop¬ 
sticks to the immediate left and right before he can eat. This prevents adjacent philosophers 
from eating at the same time. Each philosopher repeats a cycle of acquiring chopsticks, eat¬ 
ing, relinquishing chopsticks, and then thinking, until no more rice remains. If each philos¬ 
opher initially picks up the chopstick on the left before any philosopher has a chance to pick 
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up the one on the right, deadlock will occur. Deadlock will not occur if a server assures that 
no more than N-1 philosophers are allowed to eat at a time [Bums and Wellings, 1995]. 

The test scenario used a time-scale measured in milliseconds to allow target plat¬ 
form overhead effects to be expressed in the actual DP-program execution. DP eating and 
thinking activity-durations were chosen so that the ideal case would exhibit both concurrent 
and non-concurrent eating periods over a relatively small time period. 

The initial condition for the test scenario consisted of five philosophers and ten 
available bites of rice. Each eating-period duration for the philosophers Plato, Hegel and 
Descartes, was 150 milliseconds (ms) and their thinking-period duration was 250 ms. The 
eating-period duration for Lao Tsu and Socrates was 250 ms and their thinking-period du¬ 
ration was 500 ms. Figure 5-1 shows the physical arrangement of the plates and chopsticks 
for the five philosophers seated at the table. The OOA models shown in Fig. C-1 through 



Figure 5.1. Physical Arrangement of Di nin g 
Philosophers 
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Fig. C-6 specify the solution implemented in the MPS-based DP test application. The ar¬ 
rows in Fig. 5-1 represent relationships R1 and R2 in the DP object information model 
(OIM) shown in Fig. C-1. The arrows emanate from the seating position for the philosopher 
that owns the referential attributes for the designated relationship. Relationship R1 denotes 
the philosopher seated to the right of the philosopher that owns the referential attribute that 
formalizes relationship R1. Relationship R2 denotes the chopstick to the left of the philos¬ 
opher that owns the referential attribute that formalizes relationship R2. 

The ideal case was defined as hypothetical DP-program execution on a platform 
with a perfect system clock an no execution overhead. The ideal case is shown in Fig. 5-2. 
Thinking and eating activities are indicated for each philosopher by relatively lower and 
higher line segment height. The ten line segments with the highest of the three heights iden¬ 
tify the times that the rice was consumed. Plato and Descartes eat simultaneously between 
1350 ms and 1400 ms and Plato and Lao Tsu eat simultaneously between 1400 ms and 1500 



Figure 5.2. Dining Philosophers: Ideal Case 
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ms. Figure 5-1 shows that Plato is not adjacent to Lao Tsu or Descartes. 

No satisfactory estimate of context-switch time was obtained during the investiga¬ 
tion presented in this thesis. Context-switch time was measured as the time taken for a 
number of threads, N, that were blocked at a wait statement to run. This approach was not 
perfected. Available memory also limited N to 1200, and N was not large enough to meet 
the accuracy criterion of > 2V(pMJ) for p=0. 1. Nevertheless, the context-switch time es¬ 
timate of 0.7 ms was incorporated into the MPPM to demonstrate SMPS functionality. 

The other feature-time estimates (FTE) are relatively precise xmder the DL assump¬ 
tion. The number of control loop and experimental loop iterations, N, ranged from 2*^ to 
2^^. The measurement error for AMf was ±2 t, so the accuracy of Mf was computed as 2 t/ 
N. This yielded accuracies that ranged from ±3x10-7 ms to ±6x10-5 ms for FTEs that were 
obtained with the standard DL approach. This demonstrates the potential to acquire FTEs 



Elapsed Time (ms) 


Figure 5.3. Dining Philosophers: SMPS Execution 
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that are relatively accurate under the DL assumption. 

The actual SMPS DP-program execution used the partial MPPM described in chap¬ 
ter four. Figure 5-3 shows that the eating and thinking order is the same in both the SMPS 
DP-program and the ideal case. However, there are relatively small differences in timing 
between the two. These differences are due to differences in the models of system time and 
the contribution of the MPPM to SMPS timing. In the ideal case, no time elapses during 
Plato’s transition from Created to Wait shown in Fig. C-2. However, 1.4017 ms elapses 
during the same transition in the SMPS DP-program. This is shown in section D.l of Ap¬ 
pendix D, which contains the application-level program-traces for the SMPS DP-program. 
Lines two through seven in section D.l indicate that 1.4017 ms is consumed by Plato’s tran¬ 
sition from Created to Wait. Section D.2 shows the SMPS-level program traces that corre¬ 
spond to lines six and seven in section D.l This shows three components to the transition 
time. The first is the 0.7 ms start-up context-switch time for the timer thread indicated on 
lines 14-15. The second is the 0.7 ms start-up context-switch time for the activator thread 
shown on lines 23-25. The third is the activator’s 0.0017 ms message acquisition-time for 
the initial PI event for the transition from Created to Wait that is indicated on lines 23-25. 

In the ideal case, Hegel begins to eat a bite of rice during 150-300 ms. However, 
line 59 in section D.l shows that at 152.9148 ms, Hegel schedules eating to complete at 
T=290 ms. The actual completion time is shown on line 62 to be at T=291.4098 ms. The 
difference between the ideal and actual start times of T=150 ms and T=152.9148 ms is due 
to the SMPS model of MPS overhead. However, the difference between the ideal 300 ms 
completion time and the scheduled 290 ms completion time is due to the model of the ap¬ 
plication-level view of system-clock resolution. At any time, T, the value returned to the 
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application by the simulated system-clock function would be LL(r/T)jTj. When 7= 152.9148 
and 1=15.625, the value returned from the simulated system-clock function is 140. When 
the 150 ms eating-time duration is added, the 290 ms time correctly reflects what the com¬ 
pletion time should be based on the MPPM used in the SMPS DP demonstration. 

B. PERIODIC HARMONIC TASK SET WITH RMS PRIORITY ASSIGN¬ 
MENT 

This MPS-based RMS program was developed to study SMPS timing and the mod¬ 
el of a preemptive multi-threaded run-time system. The program modelled three independ¬ 
ent periodic tasks: TO, Tl, and T2. Each task had a workload and a period in which to 
complete its work. The ideal RMS scenario was based on the assumption that there was a 
perfect system clock, no system overhead, and no MPS overhead. 

The workloads (wl) chosen for the experiment were 20,40, and 80 milliseconds and 
task periods (pd) were 62, 124, and 248 milliseconds, respectively. Priority assignments 
were inversely related to task period, in accordance with RMS principles. These conditions 
were designed for high CPU utiliaation so that the addition of MPS overhead in the SMPS 
version might cause a task to fail to complete its workload by the end of its period. 

All three tasks were started at the same time and timing data were gathered until the 
end of lowest priority task’s first period. The RMS critical zone theorem states: “For a set 
of independent periodic tasks, if each task meets its first deadline when all tasks are started 
at the same time, then the deadlines will always be met for any combination of start times” 
[Sha and Goodenough, 1990]. 

In the SMPS version, activators AO, Al, and A2 provided the execution context for 
the three tasks the tasks TO, Tl, and T2. Task behavior was modelled with a specialization 
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of MpsObject and a specialization of MpsMessage. The MpsObject specialization had 
work and wait methods. Work modelled task workload execution by executing the MpsOb¬ 
ject addToActionTime method. Wait modelled delay by scheduling the MpsMessage in¬ 
stance to be delivered at the end of the period. 

Figure 5-4 shows the task execution patterns for the ideal case. TO executed its 
workload four times, consuming 80 ms of CPU time. T1 executed its workload two times, 
also consuming 80 ms of CPU time. T2 executed its workload once, also consuming 80 ms 
of CPU time. T2 completed its workload at time T=240 ms, close to the end of its period at 
T=248 ms. T2 started executing its workload at T=60 ms, but was preempted by TO at T=62 
ms and T=186 ms. 

Figure 5-5 shows the task execution patterns for the SMPS version. The SMPS ver¬ 
sion has three activator threads and the timer thread. The activators execute at their activate 
priority (P^), or else at maximum priority (P=4). They operate at maximum priority when¬ 
ever they perform any processing other than activate method processing. Figure A-4 shows 
the points in the state model at which the activators raise and lower priority. The two line 
segment levels in each activator plot in Fig. 5-5 denote activate-method processing and 
higher priority processing. The timer thread always operates at the maximum priority. The 
spikes in the timer plot denote points at which the timer either gets a message or transfers 
a message to an activator buffer. T1 was not preempted in the ideal case because the sum 
of the workloads for TO and T1 was less than Tl’s period. However, there is overhead due 
to four context switches and message handling before time T=60 ms in the SMPS version. 
The four context switches consume 2.8 ms of CPU time, in accordance with the MPPM. 
This is enough CPU time to assure that T1 does not complete its workload within TO’s pe- 
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riod. This is depicted by the spike at T=85.3 ms in Al’s plot and represents the small 
amount of CPU time remaining for A1 to complete Tl’s workload. Section D.3 provides 
detailed program traces for the preemption activity that takes place during the interval from 
T=62 ms to T=63.4 ms. Context switching and message handling consume enough CPU¬ 
time to prevent T2 from completing its workload before the end of its period. T2 executes 
73.16 ms of its workload by the end of its period at T=248, with 6.84 ms remaining. 

C. SUMMARY 

An MPS-based solution to the “Dining Philosophers” (DP) and an MPS-based pro¬ 
gram with Rate Monotonic Scheduling (RMS) priority assignments were developed to test 
the uniprocessor SMPS timing, synchronization, and the model of preemption. The actual 
behavior was compared to ideal behavior of the DP and RMS programs. The SMPS DP pro¬ 
gram had the same ordering of eating, thinking and waiting activities as the ideal case and 
appeared to have the same synchronization properties as the ideal case. Small differences 
between ideal DP timing and actual SMPS DP timing were observed. However, the ob- 
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Figure 5.4. Ideal Task Execution Patterns for Three Tasks Avith 
RMS Priority Assignments 
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served differences in timing were found to correctly reflect the MPPM. 

The RMS program was designed to exhibit high CPU utilization. The ideal case had 
eight ms of unused CPU-time in the lowest priority task’s first period. In the SMPS version, 
the lowest priority task failed to complete its workload within its period. This result cor¬ 
rectly reflected the effect of MPS overhead for the MPPM used in the experiment. 

The results of the demonstrations indicate that it is feasible to develop a discrete- 
event simulation (DES) implementation of a software architecture that has application bi¬ 
nary-code consistency (ABCC) with an implementation designed for a tiniprocessor-based 
target execution-environment. The distributed-systems question adds another dimension to 
the imiprocessor question, but does not add new research questions. There are two prob¬ 
lems in the distributed-systems question. The first is how to model a multiprocessor-based 
single-platform system. The approach developed in this investigation can address that 
problem as a variation of the same software architecture. Figure A-7 shows an object infor- 
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mation model (OIM) for a simulation model of a simulated multiprocessor-based MPS. Re¬ 
lationship R17 shown in Fig. A-7 indicates the possibility of multiple processors under the 
control of a single run-time executive. Relationship R16 denotes the relationship between 
threads in the running state and the associated CPU. No modifications to the thread state 
models shown in Fig. A-6 would be required to accommodate a multiprocessor-based mod¬ 
el. The RTE state model would be the only state model affected by the new requirement. 
Figure A-8 shows the state model for a multiprocessor-based RTE. The difference between 
the SMPS RTE state model shown in Fig. A-5 and the SDMPS RTE state model shown in 
Fig. A-8 is that the SDMPS RTE assigns eligible threads to processors. 

The second problem in the distributed-systems question is how to model multiple 
communicating platforms. This would require modelling the communication system as a 
separate architectural domain. Simulation models of communication networks are often 
used to assist in making design decisions and to do protocol testing. Network simulation 
techniques could be used to develop a simulation model of the communication system do¬ 
main. Figure A-9 shows a domain model for a simulated MPS-based distributed applica¬ 
tion. 

Multiple MPPMs would also have to be accessible to the simulation model of a het¬ 
erogeneous distributed system. SDMPS sub-paths could contain function calls that accept¬ 
ed an MPPM parameter to obtain ETEs for the correct platform rather than have hard-coded 
MPPM ETEs in the SDMPS. 
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VL CONCLUSIONS AND RECOMMENDATIONS 


The investigation presented in this thesis was concerned with two questions related 
to avoiding the probe effect in testing real-time software implemented in high-level lan¬ 
guages (HLL) developed using Object-Oriented Analysis (00A). The uniprocessor ques¬ 
tion is whether it is feasible to develop a simulation model of an application-independent 
software-architecture and environment in which to execute the same HLL application-level 
binary code as would execute in a uniprocesor-based execution-environment. The distrib¬ 
uted-systems question is whether it is feasible to extend the approach to distributed real¬ 
time applications. 

The first section of this chapter summarizes the investigation and states the conclu¬ 
sions. The second section discusses the implications of this research for related subject ar¬ 
eas and makes recommendations for further research. 

A. SUMMARY AND CONCLUSIONS 

Implementations of the same software architecture (SA) that generate the same pro¬ 
gram results with the same application-level binary-code have application-binary-code 
consistency (ABCC). This investigation employed a message-passing subsystem (MPS) 
software-architecture and a discrete-event simulation (DES) model of the MPS (SMPS) to 
investigate the uniprocessor question. An SMPS that has ABCC with the MPS supports ap¬ 
plication-level software testing conducted under controllable conditions free of the probe 
effect. 

The study used the MPS to implement a set of state-machine execution-engines that 
execute 00A state-model actions (SMA). It restricted application-level SMAs to using the 
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MPS interface for all timing and synchronization operations. The approach also imposed a 
data-access policy and a synchronization-policy that assured mutually exclusive access to 
relevant data by each active object for the duration of its SMA. 

The MPS design resolved the conflicting views of time between a real application 
and a DES-application. The MPS design restricted the SMA view of time to that provided 
by a logical clock that was only updated to “actual time” at the beginning of each SMA ex¬ 
ecution. SMA event-transmission was postponed until SMA completion in both the MPS 
and the SMPS. These two design properties supported ABCC by precluding the necessity 
to factor SMA application-code into multiple DES events for the SMPS. 

The SMPS used an MPS platform-performance model (MPPM). The MPPM con¬ 
tained a model of the system clock function resolution for the target platform. All SMPS 
functions that accessed the system clock function relied on this model of clock resolution. 
The MPPM also contained a set of functions that returned MPS execution-time estimates 
(ETE) that model the execution-times of MPS module sub-paths under MPS-application 
execution conditions in a target environment. The study used a dual-loop (DL) approach to 
acquire the MPPM ETEs for the target execution-environment. The SMPS sub-paths con¬ 
tained hard-coded MPPM ETEs that were accumulated on-the-fly to obtain SMPS opera¬ 
tion execution-time estimates. The SMPS used the ETEs to schedule the completion of 
SMPS SAs as DES events. 

The investigation developed two MPS-based applications to investigate SMPS tim¬ 
ing, synchronization, and the SMPS model of a preemptive multi-threaded run-time sys¬ 
tem. The applications had well-understood synchronization and timing properties. Each 
demonstration program ideal case was defined as hypothetical program execution on a plat- 
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form with a perfect system clock and no execution overhead. The SMPS-based implemen¬ 
tation of a uniprocessor model exhibited the desired behavior during the observation 
periods by only deviating from the ideal case by the amount expected for the MPPM. 

The results of the investigation indicated that it is feasible to develop a DBS imple¬ 
mentation of a SA that has ABCC with an implementation designed for a uniprocessor ex¬ 
ecution-environment. However, several conditions must be met. First, program sub-path 
execution-times must be predictable in the target environment. Second, the program sub¬ 
path execution times of the real implementation must be available as a platform-perform¬ 
ance-model to be incorporated into the simulation model. Finally, given a valid platform- 
performance-model, it must be possible to duplicate the timing properties of the real pro¬ 
gram in a simulation model. 

The distributed-systems question did not add new research questions, so no separate 
investigation was conducted. There are two problems in the distributed-systems question. 
The first is how to model a multiprocessor-based single-platform system. The second is 
how to model multiple heterogeneous communicating platforms. The techniques devel¬ 
oped in this investigation for the uniprocessor case could be extended to address the first 
problem. Network simulation techniques could be used to address the second problem. 

The research reported in this thesis examined feature timing using an empirical ap¬ 
proach. A need for realistic timing motivated this approach, but any empirical approach is 
limited by the conditions under which the study is conducted. This approach is expected to 
scale well to larger subsets of the Java language, and may apply readily to other languages, 
but this has not yet been proven. The results reported in this thesis offer a direction of in¬ 
quiry, not a conclusive argument for applicability to any specific project. 
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B. RECOMMENDATIONS 


The approach developed in this investigation allows the same HLL application-lev- 
el binary-code to execute in both a target execution-environment and in a simulation model. 
This property enables software test designers to disregard the intrusive effects of source 
code instrumentation in application-level software testing. However, the benefit of this ap¬ 
proach is not necessarily limited to testing application-level software. It extends to any 
service-domain that uses the modelled domain and can also be used for service-domain and 
application integration testing. 

The approach will also add value to OOA-based software development environ¬ 
ments that automatically generate source code fi-om OOA models. The SMM BridgePoint 
toolset from Project Technology^ uses an application-instance-to-architecture-instance 
mapping and a system-construction engine to generate applications from OOA models 
[Shlaer and Mellor 1997]. BridgePoint contains a model verifier that executes the state 
models in an OOA model before code generation. The approach developed in this investi¬ 
gation allows designers to test the correctness of their application-instance-to-architecture- 
instance mappings in an environment free of the probe effect by executing the generated 
code in a simulation model. 

This approach is also useful in distributed systems and network-protocol software 
development. Network-protocol error-recovery software makes frequent use of timeouts to 
detect message-delivery failures. Higher performance protocols have tighter timing con¬ 
straints and are often very time-sensitive. Network-protocol design often involves develop¬ 
ing a separate simulation model using network simulation tools such as OPNET^ or ns^. 

1. Project Technology, Inc. 7400 N. Oracle Rd. Suite 365 Tucson, AZ 85704, http;//www.pro- 
jtechxom 
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However, the approach presented in this thesis can be used to run the actual protocol and 
application code in the simulation model. This avoids questions about differences between 
the protocol software and the protocol simulation and only requires a single protocol im¬ 
plementation. 

This investigation employed an SA-based approach that is essentially language-in- 
dependent. However, language-specific SA-independent approaches are also worth consid¬ 
ering [Huang et al. 1983]. This may be achieved in Java by developing a Java class-file 
compiler that replaces the Thread-rtldieA bytecodes in class-files with simulated Thread 
bytecodes. This approach would require developing a bytecode-level MPPM and instru¬ 
menting the class-files with CPU-time accumulation operations as part of class-file 
compilation. This approach would be widely applicable to Java programs. It would also re¬ 
quire no source-code level modifications and has the advantage that only a single DL test- 
suite would need to be developed for the set of Java byte-codes. However, additional work 
would be needed to extend the approach to encompass many of the standard Java libraries. 


2. MIL 3, Inc. • 3400 International Drive, NW ■ Washington, DC • 20008. http://www.mil3.com/ 
products/modeler/s imcycle. htm 1. 

3. UCB/LBNL/VINT Network Simulator - ns (version 2), http://mash.cs.berkeley.edu/ns/ns.html 
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APPENDIX A. MPS AND SMPS OOA MODEL DIAGRAMS 



Figure A-1. MPS Object Information Model 





MPS/RTE 



Figure A-2. SMPS Object Information Model 







Created 

tid = create thread(id) 


Starting 

%g RTE1: ready (tid) 


Waiting for Message 
%g TH3:block(tid) 


Transfer Msg 
if tbuff nonempty{ 
msg = get message 
msg.dest.put(msg) 
if msg.deststate = WFM { 
act = msg.dest 
time += get+put+notify 

} 

else 

time += get+put 

} 

%g TIM1(TH3, time, id) 


Interruptedi 
%g RTE1; ready (tid) 


CtxToRunning2 
%g TIM1(TH3, now+ctxtm) 


CtxToRunningi n 
% g TIM1(TH3, now+ctxtm)y 


Interrupted2 
%g RTE1;ready(tid) 


Getting Message 
if no message 
%g TH4;wait(id) 
else{ 

%g TH3:continue(id) 


/ Timeout 

mat = msg.activation time 
I —^ %g TIM1 :set timer 
(TH1, mat, tid) 

■^%g TH3:block(tid) 


Figure A-3. SMPS Timer State Model 






( Getting Message 
if empty message buffer 
%g TH4:wait(id) 
else{ 

msg = get msg 
gmt = sclock + get time 
%g TIM1:set timer 
V (TH3, gmt, id) } 


( CtxSwToRunningl ' 
\®/ogTH1(TH3, now+ctxTm). 


Transferring Msgs 
set priority to max 
while non-empty tbuff { 
m = tbuff.get 
dest.buff.put(m) 
if m.dest.state=WFM { 
time = get+put+notify 
%g TH1 :ready(m.dest) 

} 

else 

time = get+put 

} 

%g TIM1:set timer 
MTH3, now+time) 


Interrupted 
%g RTE1:ready(tid) 


f CtxSwToRunning2 ' 
raise priority 

V%g TH1(TH3, now+ctxTm)y 


( Waiting for Message 
l%g TH3:block{tid) 


f Preempted 
%g TIM2;cancel(e id) 
consumed = sclock()-start 
XT rem -= consumed 


/ Starting 

%g TH1:ready(tid) 
'^et priority to max 


/ Activating 
start = sclock 
restorePri 

\%g TIM1(TH3, now+Trem) 


Created 

tid = “/ocreate thread(id) 


Activate 
set pri to default 
update eclock 
msg.activateO 
THS activatendl 


Figure A-4. SMPS Activator State Model 







Figiire A-5. SMPS Run-Time Executive State Model 
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Figure A-6. SMPS Thread State Model 
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Figure A-7. Multiprocessor-based MPS Object Information Model 






f Blocking 

%g TH3:block(rid) 
find CPU (R17) with R16==rid 
tid = get 

highest pri ready thread 
if tid valid 
R17.R16 = tid 
%g TH2:run(tid) 
else 

R17.R16 = undefined 
l%g RTE4:idle 


RTE2:idle RTE3:block 



RTE1; 

ready(tid) 


RTE2:idle 


' Checking 

rid = running thread 
if tid higher pri than rid { 
find CPU (R17) with R16==rid 
%g TH1:ready(rid) 
running thread = tid 
R17.R16 = tid 
%g TH2;run(tid) 

} 


Figure A-8. Multiprocessor-based MPS Run-Time 
Executive State Model 
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Figure A-9. Domain Model for a Simulated MPS-based Distributed 

Application 
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APPENDIX B. MPPM SOURCE CODE EXAMPLES 


public final class ClockRes2 

{ 

static long[] time = new long[1000000]; 


} 


public static void main(String args[]) 

{ 

int count = 0; 

double sum = 0.0; 

for (int test=0; test<10; test++) 

{ 

for (int idx=0; idx<time.length; idx++) 
time[idx] = System.currentTimeMillis(); 
for (int idx=l; idx<time.length; idx++) 

{ 

if (time[idx] > time[idx-l]) 

{ 


} 


count++; 

long diff = time[idx] - time[idx-l]; 
sum = sum + (double)(time[idx] 

- time[idx-1]); 


} 


} 

System.out.println("resolution; " 

+ (sum/(double)count) 


} 


+ " ms") ; 


Figurre B-1. Program to Determine the Resolution of the 
Fundamental Time Unit Returned by Java System.currentTimeMillis 


83 




/** Get the current system time. 

* @return current system time in milliseconds. 
*/ 

public long millisO 

{ 

double time = Clock.get() //sim clock; 
time = Math.floor(Tcr*Math.floor(time/Tcr)); 
return (long) time; 

} 


Figure B-2. The SMPS Model of the Java 
System.currentTimeMillis Method in class MpsRealClock 
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public final class DelayResolution extends Thread 

{ 

static final int N = 50, trials = 30; 
static final long [] 
time = new long [N * trials], 
mtime = new long [N * trials]; 
static int ctr = 0; 

public static void main(String args[]) 

{ 

object t = new object(); 

for (int idx =0; idx < N; idx++) 

for (int trial = 0; trial < trials; trial++; 

{ 

rtime[ctr] = (long )(idx + 1); 
mtime[ctr] = t.Wait(rtime[ctr]); 
ctr++; 

} 

System,out.println ("0, "); 

for (int idx =0; idx < rtime.length; idx++) 
System.out.println("" 

+ rtime[idx] + ”, " + mtime[idx]); 


class object extends Object 

{ 

public synchronized long Wait(long time) 

{ 

long start = 0; 
try 
{ 

start = System.currentTimeMillis0; 
wait(time); 

return System.currentTimeMillis() - start; 

} 

catch (InterruptedException e) 

{ 

System.out.println(e,toString()); 
return -1; 

} 


Figure B-3. Program to Examine the Resolution of the 
Java wait Statement 
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//%%/** Execution time estimate of 1st path.*/ 
//%%private static final double 
//%%Vappend_lmf = "method.mipubvlpMf" 

//%% + "cond.iVbEqcVbMf" 

//%% + 2*"assign.iloloMf" 

//%% + "MpsNodeTO.updateNextNullMf"; 

//%%/** Execution time estimate of 2nd path.*/ 
//%%private static final double 
//%%Vappend_2mf = "method.mipubvlpMf" 

//%% + "cond.iVbEqcVbMf" 

//%% + "assign.iloloMf" 

//%% + "MpsNodeTO.updateNextMf" 

//%% + "MpsNodeTO.updateNextNullMf"; 

/** Appends MpsMessage to buffer. 

* @param msg the message to be appended. */ 
final void append(CpuCharger cc, MpsMessage msg] 

if (front == null) 

{ 

back = msg; 

front = msg; 

msg.updateNext(null); 

//%%cc.charge(Vappend_lmf); 


else 


back.updateNext(msg); 
msg.updateNext(null); 
back = msg; 

//%%cc.charge(Vappend_2mf] 


Figure B-4. MpsFifo.append Mdhod Before ETE Inlining 
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/** Execution time estimate of 1st path.*/ 
private static final double 
Vappend_lmf = 3.320018450419108E-4 
+ 2.449154853820801E-4 
+ 2*4.805326461791992E-4 
+ 4.1353702545166016E-4; 

/** Execution time estimate of 2nd path.*/ 
private static final double 
Vappend_2mf = 3.320018450419108E-4 
+ 2.449154853820801E-4 
+ 4.805326461791992E-4 
+ 5.21540641784668E-4 
+ 4.1353702545166016E-4; 

/** Appends MpsMessage to buffer. 

* @param msg the message to be appended. */ 
final void append(CpuCharger cc, MpsMessage msg) 
{ 

if (front == null) 

{ 

back = msg; 
front = msg; 
msg.updateNext(null) ; 
cc.charge(Vappend_lmf); 

} 

else 

{ 

back.updateNext(msg); 
msg.updateNext(null); 
back = msg; 

cc.charge(Vappend_2mf); 

} 


Figure B-5. MpsFifo.append Method After EXE Inlining 
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P2:NoRice(P Id) PI :continue(P Id) 



Figure C-2. Philosopher State Model 
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■TK2:continue(ld) 


idle 

PId = R6.22 
%g P1(Pld) 


TK1:request(LH Id, Id) I 

I TK2:continue(Id) 



TK3:none available(ld) 


Backing Off 
PId = R6 

%g P2:No Rice(Pld) 


Figure C-3. Token State Model 



/ Cleaning Up 
Cld = R6 

%g C2:releas(Cld) 
Cld = R6.R2.R1.R2 
%g C2:releas(Cld) 
%g TK_A4(Id) 

^g TK2:continue(ld) 
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Figure C-4. Token Assigner State Model 
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C1 :request(T Id, Id) C2;release(ld) 


Owned 

%gTK2:continue(Tkld) 


C1:request(Tkld, | 

Id) Cl:request(Tkld, Id) 



Figure C-5. Chopstick State Model 



Figure C-6. Rice State Model 
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APPENDIX D. DINING PHILOSOPHER PROGRAM EXECUTION TRACES 


D.l. APPLICATION-LEVEL TRACE 


This section contains the complete execution trace for the application-level activi¬ 


ties in the SMPS DP program. Each application-level trace statement has a line number, the 


simulation time in brackets, the object state, and may also have a message pertaining to the 


state. 


1 [0.0000] TOK_A IDLE 

2 [0.0000] Plato CREATED 

3 [0.0000] Hegel CREATED 

4 [0.0000] Decartes CREATED 

5 [0.0000] Lao Tsu CREATED 

6 [0.0000] Socrates CREATED 

7 [1.4017] Plato WAITING: %g TK_A1(Plato) to Token_A 

8 [1.4093] Hegel WAITING: %g TK_A1(Hegel) to Token_A 

9 [1.4170] Decartes WAITING: %g TK_A1(Decartes) to Token_A 

10 [1.4247] Lao Tsu WAITING: %g TK_A1(Lao Tsu) to Token_A“ 

11 [1.4323] Socrates WAITING: %g TK_A1(Socrates) to Token_A 

12 [1.4400] TOK_A REQUESTING: TOK_0 is avail: %g TK1(CS_0) to TOK 0 

13 [1.4400] TOK_A IDLE 

14 [1.4476] TOK_A REQUESTING: TOK_l is avail: %g TK1(CS_1) to TOK 1 

15 [1.4476] TOK_A IDLE 

16 [1.4553] TOK_A REQUESTING: TOK_2 is avail: %g TK1(CS_2) to TOK 2 

17 [1.4553] TOK_A IDLE 

18 [1.4629] TOK_A REQUESTING: TOK_3 is avail: %g TKl(CS 3) to TOK 3 

19 [1.4629] TOK_A IDLE 

20 [1.4706] TOK_A REQUESTING: no avail tokens, Socrates pending 

21 [1.4706] TOK_A IDLE 

22 [1.4723] TOK_0 WAITING_FOR_LC: %g Cl to CS_0 

23 [1.4799] TOK_l WAITING_FOR_LC: %g Cl to CS_1 

24 [1.4876] TOK_2 WAITING_FOR_LC: %g Cl to CS_2 

25 [1.4952] TOK_3 WAITING_FOR_LC: %g Cl to CS_3 

26 [1.5029] CS_0 OWNED: %g TK2 to TOK_0 

27 [1.5105] CS_1 OWNED: %g TK2 to TOK_l 

28 [1.5182] CS_2 OWNED: %g TK2 to TOK_2 

29 [1.5258] CS_3 OWNED: %g TK2 to TOK_3 

30 [1.5335] TOK_0 WAITING_FOR_RC: %g Cl to CS_4 

31 [1.5411] TOK_l WAITING_FOR_RC: %g Cl to CS_0 

32 [1.5488] TOK_2 WAITING_FOR_RC: %g Cl to CS_1 

33 [1.5564] TOK_3 WAITING_FOR_RC: %g Cl to CS_2 

34 [1.5641] CS_4 OWNED: %g TK2 to TOK_0 

35 [1.5718] CS_0 RESERVED 

36 [1.5734] CS_1 RESERVED 

37 [1.5751] CS_2 RESERVED 

38 [1.5771] TOK_0 WAITING_FOR_RICE: %g R1 to Rice 

39 [1.5851] RICE %g TK2 to TOK_0, 9 bites remaining 

40 [1.5930] TOK_0 WAITING_FOR_PHILOSOPHER: %g PI to Plato 

41 [1.6010] Plato EAT: scheduling PI to self at 150ms 

42 [151.4095] Plato RELINQUISHING: %g TK2 to TOK_0 

43 [151.4174] TOK_0 CLEANING_UP: %g C2 to CS_0 

44 [151.4174] TOK_0 CLEANING_UP: %g C2 to CS_4 

45 [151.4174] TOK_0 CLEANING_UP: %g TK_A4 to Token_A 
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46 [151.4421] CS_0 REQUESTING: %g Cl self-event 

47 [151.4421] CS_0 OWNED: %g TK2 to TOK 1 

48 [151.4497] CS_4 UNOWNED 

49 [151.4514] TOK_A RELINQUISHING: TOK_0 avail, %g TK_A2 self-event 

50 [151.4514] TOK_A IDLE: %g TK_A1(Socrates) to self 

51 [151.4591] Plato THINK: scheduling PI to self at 390ms 

52 [151.4689] TOK_l WAITING_FOR_RICE: %g R1 to Rice 

53 [152.8766] TOK_A REQUESTING: TOK 0 is avail: %g TKl(CS 4) to TOK 0 

54 [152.8766] T0K_A IDLE 

55 [152.8842] RICE %g TK2 to TOK_l, 8 bites remaining 

56 [152.8919] TOK_0 WAITING_FOR_LC: %g Cl to CS_4 

57 [152.8995] TOK_l WAITING_FOR_PHILOSOPHER: %g PI to Hegel 

58 [152.9072] CS_4 OWNED: %g TK2 to TOK_0 

59 [152.9148] Hegel EAT: scheduling PI to self at 290ms 

60 [152.9251] TOK_0 WAITING_FOR_RC: %g Cl to CS_3 

61 [154.3331] CS_3 RESERVED 

62 [291.4098] Hegel RELINQUISHING: %g TK2 to TOK_l 

63 [291.4177] T0K_1 CLEANING_UP: %g C2 to CS 1 

64 [291.4177] T0K_1 CLEANING_UP: %g C2 to CS_0 

65 [291.4177] T0K_1 CLEANING_UP: %g TK_A4 to Token A 

66 [291.4424] CS_1 REQUESTING: %g Cl self-event 

67 [291.4424] CS_1 OWNED: %g TK2 to TOK 2 

68 [291.4500] CS_0 UNOWNED 

69 [291.4517] T0K_A RELINQUISHING: TOK 1 avail, %g TK A2 self-event 

70 [-291.4517] TOK_A IDLE 

71 [291.4534] Hegel THINK: scheduling PI to self at 531ms 

72 [291.4648] TOK_2 WAITING_FOR_RICE: %g R1 to Rice 

73 [291.4728] RICE %g TK2 to TOK_2, 7 bites remaining 

74 [291.4807] TOK_2 WAITING_FOR_PHILOSOPHER: %g PI to Decartes 

75 [291.4887] Decartes EAT: scheduling PI to self at 431ms 

76 [391.4098] Plato WAITING: %g TK_A1(Plato) to Token_A 

77 [391.4177] TOK_A REQUESTING: TOKl is avail: %g TKl(CS 0) to TOK 1. 

78 [391.4177] TOK_A IDLE ~ “ 

79 [391.4257] TOK_l WAITING_FOR_LC: %g Cl to CS 0 

80 [391.4336] CS_0 OWNED: %g TK2 to TOK_l 

81 [391.4415] TOK_l WAITING_FOR_RC: %g Cl to CS 4 

82 [391.4495] CS_4 RESERVED “ 

83 [432.4098] Decartes RELINQUISHING: %g TK2 to TOK 2 

84 [432.4177] T0K_2 CLEANING_UP: %g C2 to CS 2 

85 [432.4177] T0K_2 CLEANING_UP: %g C2 to CS_1 

86 [432.4177] TOK_2 CLEANING_UP: %g TK_A4 to Token A 

87 [432.4424] CS_2 REQUESTING: %g Cl self-event 

88 [432.4424] CS_2 OWNED: %g TK2 to TOK 3 

89 [432.4500] CS_1 UNOWNED 

90 [432.4517] T0K_A RELINQUISHING: TOK 2 avail, %g TK A2 self-event 

91 [432.4517] TOK_A IDLE “ “ 

92 [432.4534] Decartes THINK: scheduling PI to self at 671ms 

93 [432.4648] TOK_3 WAITING_FOR_RICE: %g R1 to Rice 

94 [432.4728] RICE %g TK2 to TOK_3, 6 bites remaining 

95 [432.4807] TOK_3 WAITING_FOR_PHILOSOPHER: %g PI to Lao Tsu 

96 [432.4887] Lao Tsu EAT: scheduling PI to self at 671ms 

97 [532.4098] Hegel WAITING: %g TK_A1(Hegel) to Token A 

98 [532.4177] TOK_A REQUESTING: TOK 2 is avail: %g TKl(CS 1) to TOK 2 

99 [532.4177] TOK_A IDLE “ ~ “ 

100 [532.4257] TOK_2 WAITING_FOR_LC: %g Cl to CS 1 

101 [532.4336] CS_1 OWNED: %g TK2 to TOK 2 

102 [532.4415] TOK_2 WAITING_FOR RC: %g Cl to CS 0 

103 [532.4495] CS_0 RESERVED 

104 [672.4098] Lao Tsu RELINQUISHING: %g TK2 to TOK_3 

105 [673.8227] Decartes WAITING: %g TK A1(Decartes) to Token A 

106 [673.8304] TOK_3 CLEANING_UP: %g C2 to CS 3 ~ 

107 [673.8304] TOK_3 CLEANING_UP: %g C2 to CS 2 

108 [673.8304] TOK_3 CLEANING_UP: %g TK_A4 to Token_A 

109 [673.8551] TOK_A REQUESTING: no avail tokens. Decartes pending 
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110 [673.8551] TOK_A IDLE 

111 [673.8568] CS_3 REQUESTING; %g Cl self-event 

112 [673.8568] CS_3 OWNED: %g TK2 to TOK_0 

113 [673.8644] CS_2 UNOWNED 

114 [673.8661] TOK_A RELINQUISHING: TOK_3 avail, %g TK A2 self-event 

115 [673.8661] TOK_A IDLE: %g TK_A1(Decartes) to self 

116 [673.8737] Lao Tsu THINK: scheduling PI to self at 1171ms 

117 [673.8836] TOK_0 WAITING_FOR_RICE; %g R1 to Rice 

118 [675.2912] TOK_A REQUESTING: TOK_3 is avail: %g TKl(CS 2) to TOK 3 

119 [675.2912] TOK_A IDLE 

120 [675.2989] RICE %g TK2 to TOK_0, 5 bites remaining 

121 [675.3066] TOK_3 WAITING_FOR_LC: %g Cl to CS_2 

122 [675.3142] TOK_0 WAITING_FOR_PHILOSOPHER: %g PI to Socrates 

123 [675.3219] CS_2 OWNED: %g TK2 to TOK_3 

124 [675.3295] Socrates EAT: scheduling PI to self at 921ms 

125 [675.3398] TOK_3 WAITING_FOR_RC: %g Cl to CS_1 

126 [676.7478] CS_1 RESERVED 

127 [922.4098] Socrates RELINQUISHING: %g TK2 to TOK_0 

128 [922.4177] TOK_0 CLEANING_UP: %g C2 to CS_4 

129 [922.4177] TOK_0 CLEANING_UP: %g C2 to CS_3 

130 [922.4177] TOK_0 CLEANING_UP; %g TK_A4 to Token A 

131 [922.4424] CS_4 REQUESTING: %g Cl self-event 

132 [922.4424] CS_4 OWNED: %g TK2 to TOK 1 

133 [922.4500] CS_3 UNOWNED 

134 [922.4517] TOK_A RELINQUISHING: TOK_0 avail, %g TK_A2 self-event 

135 [922.4517] TOK_A IDLE 

136 [922.4534] Socrates THINK: scheduling PI to self at 1421ms 

137 [922.4648] TOK_l WAITING_FOR_RICE: %g R1 to Rice 

138 [922.4728] RICE %g TK2 to TOK_l, 4 bites remaining 

139 [922.4807] TOK_l WAITING_FOR_PHILOSOPHER; %g PI to Plato 

140 [922.4887] Plato EAT: scheduling PI to self at 1071ms 

141 [1072.4098] Plato RELINQUISHING: %g TK2 to TOK_l 

142 [1072.4177] TOK_l CLEANING_UP: %g C2 to CS 0 

143 [1072.4177] TOK_l CLEANING_UP: %g C2 to CS_4 

144 [1072.4177] TOK_l CLEANING_UP: %g TK_A4 to Token_A 

145 [1072.4424] CS_0 REQUESTING: %g Cl self-event 

146 [1072.4424] CS_0 OWNED: %g TK2 to TOK_2 

147 [1072.4500] CS_4 UNOWNED 

148 [1072.4517] TOK_A RELINQUISHING: TOKl avail, %g TK A2 self-event 

149 [1072.4517] TOK_A IDLE 

150 [1072.4534] Plato THINK: scheduling PI to self at 1312ms 

151 [1072.4654] TOK_2 WAITING_FOR_RICE: %g R1 to Rice 

152 [1072.4733] RICE %g TK2 to TOK_2, 3 bites remaining 

153 [1072.4813] TOK_2 WAITING_FOR_PHILOSOPHER: %g PI to Hegel 

154 [1072.4892] Hegel EAT: scheduling PI to self at 1212ms 

155 [1172.4098] Lao Tsu WAITING: %g TK_A1{Lao Tsu) to Token_A 

156 [1172.4177] TOK_A REQUESTING: TOKO is avail: %g TK1(CS 3) to TOK 0 

157 [1172.4177] TOK_A IDLE 

158 [1172.4257] TOK_0 WAITING_FOR_LC: %g Cl to CS_3 

159 [1172.4336] CS_3 OWNED: %g TK2 to TOK_0 

160 [1172.4415] TOK_0 WAITING_FOR_RC: %g Cl to CS 2 

161 [1172.4495] CS_2 RESERVED 

162 [1213.4098] Hegel RELINQUISHING: %g TK2 to TOK_2 

163 [1213.4177] TOK_2 CLEANING_UP: %g C2 to CS_1 

164 [1213.4177] TOK_2 CLEANING_UP: %g C2 to CS_0 

165 [1213.4177] TOK_2 CLEANING_UP: %g TK_A4 to Token_A 

166 [1213.4424] CS_1 REQUESTING; %g Cl self-event 

167 [1213.4424] CS_1 OWNED; %g TK2 to TOK_3 

168 [1213.4500] CS_0 UNOWNED 

169 [1213.4517] TOK_A RELINQUISHING: TOK 2 avail, %g TK A2 self-event 

170 [1213.4517] TOK_A IDLE 

171 [1213.4534] Hegel THINK: scheduling PI to self at 1453ms 

172 [1213.4655] TOK_3 WAITING_FOR_RICE: %g R1 to Rice 

173 [1213.4734] RICE %g TK2 to TOK_3, 2 bites remaining 
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174 [1213.4814] T0K_3 WAITING_FOR_PHILOSOPHER: %g PI to Decartes 

175 [1213.4893] Decartes EAT: scheduling PI to self at 1353ms 

176 [1313.4098] Plato WAITING: %g TK_A1(Plato) to Token A 

177 [1313.4177] T0K_A REQUESTING: TOK_l is avail: %g TKl(CS 0) to TOK 1 

178 [1313.4177] TOK_A IDLE 

179 [1313.4257] T0K_1 WAITING_FOR_LC: %g Cl to CS 0 

180 [1313.4336] CS_0 OWNED: %g TK2 to T0K_1 

181 [1313.4415] T0K_1 WAITING_FOR_RC; %g Cl to CS 4 

182 [1313.4495] CS_4 OWNED: %g TK2 to TOK_l 

183 [1313.4574] TOK_l WAITING_FOR_RICE: %g R1 to Rice 

184 [1313.4654] RICE %g TK2 to TOK_l, 1 bites remaining 

185 [1313.4733] TOK_l WAITING_FOR_PHILOSOPHER: %g PI to Plato 

186 [1313.4812] Plato EAT: scheduling PI to self at 1462ms 

187 [1354.4098] Decartes RELINQUISHING: %g TK2 to TOK 3 

188 [1354.4177] TOK_3 CLEANING_UP: %g C2 to CS_2 

189 [1354.4177] T0K_3 CLEANING_UP: %g C2 to CS_1 

190 [1354.4177] T0K_3 CLEANING_UP: %g TK_A4 to Token A 

191 [1354.4424] CS_2 REQUESTING: %g Cl self-event 

192 [1354.4424] CS_2 OWNED: %g TK2 to TOK_0 

193 [1354.4500] CS_1 UNOWNED 

194 [1354.4517] T0K_A RELINQUISHING: TOK 3 avail, %g TK A2 self-event 

195 [1354.4517] T0K_A IDLE 

196 [1354.4534] Decartes THINK: scheduling PI to self at 1593ms 

197 [1354.4655] TOK_0 WAITING_FOR_RICE: %g R1 to Rice 

198 [1354.4734] RICE %g TK2 to TOK_0, 0 bites remaining 

199 [1354.4814] TOK_0 WAITING_FOR_PHILOSOPHER: %g PI to Lao Tsu 

200 [1354.4893] Lao Tsu EAT: scheduling PI to self at 1593ms 

201 [1422.4098] Socrates WAITING: %g TK_A1(Socrates) to Token A 

202 [1422.4177] TOK_A REQUESTING: TOK 2 is avail: %g TK1(CS 4) to TOK 2 

203 [1422.4177] TOK_A IDLE “ 

204 [1422.4257] TOK_2 WAITING_FOR_LC: %g Cl to CS 4 

205 [1422.4336] CS_4 RESERVED 

206 [1454.4098] Hegel WAITING: %g TK_A1(Hegel) to Token A 

207 [1454.4177] TOK_A REQUESTING: TOK_3 is avail: %g TKllCS 1) to TOK 3 

208 [1454.4177] TOK_A IDLE “ “ 

209 [1454.4257] TOK_3 WAITING_FOR_LC: %g Cl to CS 1 

210 [1454.4336] CS_1 OWNED: %g TK2 to TOK_3 

211 [1454.4415] TOK_3 WAITING_FOR_RC: %g Cl to CS 0 

212 [1454.4495] CS_0 RESERVED “ 

213 [1463.4098] Plato RELINQUISHING: %g TK2 to TOK_l 

214 [1463.4177] TOK_l CLEANING_UP: %g C2 to CS 0 

215 [1463.4177] TOK_l CLEANING_UP: %g C2 to CS_4 

216 [1463.4177] TOK_l CLEANING_UP: %g TK_A4 to Token A 

217 [1463.4424] CS_0 REQUESTING: %g Cl self-event 

218 [1463.4424] CS_0 OWNED: %g TK2 to TOK_3 

219 [1463.4500] CS_4 REQUESTING: %g Cl self-event 

220 [1463.4500] CS_4 OWNED: %g TK2 to TOK_2 

221 [1463.4577] TOK_A RELINQUISHING: TOK 1 avail, %g TK A2 self-event 

222 [1463.4577] TOK_A IDLE 

223 [1463.4594] Plato THINK: scheduling PI to self at 1703ms 

224 [1463.4711] TOK_3 WAITING_FOR_RICE: %g R1 to Rice 

225 [1463.4788] TOK_2 WAITING_FOR_RC: %g Cl to CS 3 

226 [1463.4941] CS_3 RESERVED 

227 [1463.4961] TOK_3 BACKING_OFF: %g P2 to Hegel 

228 [1463.4961] TOK_3 CLEANING_UP: %g C2 to CS_1 

229 [1463.4961] TOK_3 CLEANING_UP: %g C2 to CS 0 

230 [1463.4961] T0K_3 CLEANING_UP: %g TK A4 to Token A 

231 [1463.5264] Hegel NO_RICE ~ 

232 [1463.5281] CS_1 UNOWNED 

233 [1463.5298] CS_0 UNOWNED 

234 [1463.5315] TOK_A RELINQUISHING: TOK 3 avail, %g TK A2 self-event 

235 [1463.5315] T0K_A IDLE 

236 [1594.4098] Lao Tsu RELINQUISHING: %g TK2 to TOK 0 

237 [1595.8230] Decartes WAITING: %g TK A1(Decartes) to Token A 
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238 

[1595.8307] 

239 

[1595.8307] 

240 

[1595.8307] 

241 

[1595.8554] 

242 

[1595.8554] 

243 

[1595.8630] 

244 

[1595.8630] 

245 

[1595.8707] 

246 

[1595.8724] 

247 

[1595.8724] 

248 

[1595.8741] 

249 

[1595.8852] 

250 

[1595.8928] 

251 

[1595.9005] 

252 

[1595.9158] 

253 

[1595.9234] 

254 

[1595.9234] 

255 

[1595.9234] 

256 

[1595.9234] 

257 

[1595.9538] 

258 

[1595.9615] 

259 

[1595.9631] 

260 

[1595.9648] 

261 

[1595.9665] 

262 

[1595.9665] 

263 

[1595.9702] 

264 

[1595.9861] 

265 

[1595.9861] 

266 

[1595.9861] 

267 

[1595.9861] 

268 

[1596.0164] 

269 

[1596.0181] 

270 

[1596.0198] 

271 

[1596.0215] 

272 

[1596.0215] 

273 

[1704.4098] 

274 

[1704.4177] 

275 

[1704.4177] 

276 

[1704.4257] 

277 

[1704.4336] 

278 

[1704.4415] 

279 

[1704.4495] 

280 

[1704.4574] 

281 

[1704.4733] 

282 

[1704.4733], 

283 

[1704.4733] 

284 

[1704.4733] 

285 

[1704.5036] 

286 

[1704.5053] 

287 

[1704.5070] 

288 

[1704.5087] 

289 

[1704.5087] 

290 

[2094.4095] 

291 

[2094.4174] 

292 

[2094.4174] 

293 

[2094.4254] 

294 

[2094.4333] 

295 

[2094.4412] 

296 

[2094.4492] 

297 

[2094.4571] 

298 

[2094.4730] 

299 

[2094.4730] 

300 

[2094.4730] 

301 

[2094.4730] 


TOK_0 CLEANING_UP: %g C2 to CS_3 

TOK_0 CLEANING_UP: %g C2 to CS_2 

TOK_0 CLEANING_UP: %g TK_A4 to Token_A 

TOK_A REQUESTING: T0K_1 is avail: %g TK1(CS_2) to T0K_1 

TOK_A IDLE 

CS_3 REQUESTING: %g Cl self-event 
CS_3 OWNED: %g TK2 to T0K_2 
CS_2 UNOWNED 

TOK_A RELINQUISHING: TOK_0 avail, %g TK_A2 self-event 
TOK_A IDLE 

Lao Tsu THINK: scheduling PI to self at 2093ms 

TOK_l WAITING_FOR_LC: %g Cl to CS_2 

TOK_2 WAITING_FOR_RICE: %g R1 to Rice 

CS_2 OWNED: %g TK2 to TOK_l 

TOK_l WAITING_FOR_RC: %g Cl to CS_1 

TOK_2 BACKING_OFF: %g P2 to Socrates 

TOK_2 CLEANING_UP: %g C2 to CS_4 

TOK_2 CLEANING_UP: %g C2 to CS_3 

TOK_2 CLEANING_UP: %g TK_A4 to Token_A 

CS_1 OWNED: %g TK2 to TOK_l 

Socrates NO_RICE 

CS_4 UNOWNED 

CS_3 UNOWNED 

TOK_A RELINQUISHING: T0K_2 avail, %g TK_A2 self-event 
TOK_A IDLE 

TOK_l WAITING_FOR_RICE: %g R1 to Rice 
TOK_l BACKING_OFF: %g P2 to Decartes 
TOK_l CLEANING_UP: %g C2 to CS_2 
TOK_l CLEANING_UP: %g C2 to CS_1 
TOK_l CLEANING_UP: %g TK_A4 to Token_A 
Decartes NO_RICE 
CS_2 UNOWNED 
CS_1 UNOWNED 

TOK_A RELINQUISHING: T0K_1 avail, %g TK_A2 self-event 
TOK_A IDLE 

Plato WAITING: %g TK_A1(Plato) to Token_A 

TOK_A REQUESTING: TOK_0 is avail: %g TK1{CS_0) to TOK_0 

TOK_A IDLE 

TOK_0 WAITING_FOR_LC: %g Cl to CS_0 
CS_0 OWNED: %g TK2 to TOK_0 
TOK_0 WAITING_FOR_RC: %g Cl to CS_4 
CS_4 OWNED: %g TK2 to TOK_0 
TOK_0 WAITING_FOR_RICE: %g R1 to Rice 
TOK_0 BACKING_OFF: %g P2 to Plato 
TOK_0 CLEANING_UP: %g C2 to CS_0 
TOK_0 CLEANING_UP: %g C2 to CS_4 
TOK_0 CLEANING_UP: %g TK_A4 to Token_A 
Plato NO_RICE 
CS_0 UNOWNED 
CS_4 UNOWNED 

TOK_A RELINQUISHING: TOK_0 avail, %g TK_A2 self-event 
TOK A IDLE 


Lao Tsu WAITING: %g TK_Al(Lao Tsu) to Token_A 

TOK_A REQUESTING: TOK_0 is avail: %g TK1(CS_3) to TOK_0 

TOK_A IDLE 

TOK_0 WAITING_FOR_LC: %g Cl to CS_3 
CS_3 OWNED: %g TK2 to TOK_0 
TOK_0 WAITING_FOR_RC: %g Cl to CS_2 
CS_2 OWNED: %g TK2 to TOK_0 
TOK_0 WAITING_FOR_RICE: %g R1 to Rice 
TOK_0 BACKING_OFF: %g P2 to Lao Tsu 
TOK 0 CLEANING UP: %g C2 to CS_3 

%g C2 to CS_2 
%g TK A4 to Token A 


TOK_0 CLEANING_UP 
TOK 0 CLEANING UP 
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302 [2094.5033] Lao Tsu NO_RICE 

303 [2094.5050] CS_3 UNOWNED 

304 [2094.5067] CS_2 UNOWNED 

305 [2094.5084] TOK_A RELINQUISHING: TOK_0 avail, %g TK A2 self-event 

306 [2094.5084] TOK_A IDLE 

307 [2094.5104] Plato spent 450 ms eating 3 bites of rice and 750 ms 

thinking 

308 [2094.5104] Hegel spent 300 ms eating 2 bites of rice and 500 ms 
thinking 

309 [2094.5104] Decartes spent 300 ms eating 2 bites of rice and 500 ms 
thinking 

310 [2094.5104] Lao Tsu spent 500 ms eating 2 bites of rice and 1000 ms 
thinking 

311 [2094.5104] Socrates spent 250 ms eating 1 bites of rice and 500 ms 
thinking 

D.2 SMPS-LEVEL TRACES: CREATED TO WAIT 


This section has the SMPS-level traces that underly execution indicated by lines six 
and seven shown in section D.l. SMPS-level trace statement have a line number, the sim¬ 
ulation time in brackets and a message. The message does not always print object state. 

1 [0000.0000] Socrates CREATED 

2 [0000.0000] mps initSend: PI(Plato) 

3 [0000.0000] mps initSend: PI(Hegel) 

4 [0000.0000] mps initSend: Pl(Decartes) 

5 [0000.0000] mps initSend: Pl(Lao Tsu) 

6 [0000.0000] mps initSend: PI(Socrates) 

7 [0000.0000] mps starting activators 

8 [0000.0000] MpsTimer sending cp.mps.MpsTimerSTHl to TIMER t:0.0 

9 [0000.0000] mps starting activator 0 

10 [0000.0000] MpsActivatorO THl to MpsActivatorO S[CREATED,BLOCKED] 
p:9 t:0.0 delivered 

11 [0000.0000] MpsActivatorO EXECUTING STARTING-action [READY] P:9 

12 [0000.0000] MpsTimer executing STARTING [READY] pri:10 

13 [0000.0000] MpsTimer sending TH2 to MpsTimer S[STARTING,READY] t:- 

1.0 

14 [0000.0000] MpsTimer executing CTXSW_T0_RUNNING1 [RUNNING] pri:10 

15 [0000.7000] MpsTimer executing GETTING_MSG [RUNNING] pri:10 

16 [0000.7000] MpsTimer executing WAITING_FOR_MSG [BLOCKED] pri:10 

17 [0000.7000] MpsActivatorO sending TH2 to MpsActivatorO S[START¬ 

ING, READY] p:9 t:-1.0 

18 [0000.7000] MpsActivatorO TH2 to MpsActivatorO S[STARTING,READY] 
p:9 t:-1.0 delivered 

19 [0000.7000] MpsActivatorO EXECUTING CTXSW TO RUNNINGl-action [RUN¬ 
NING] P:9 ~ ~ 

20 [0000.7000] MpsActivatorO delayedDelivery 1.4 

21 [0001.4000] MpsActivatorO TH3 to ,MpsActivatorO 

S[CTXSW_T0_RUNNING1, RUNNING] p:9 t:1.4 delivered 

22 [0001.4000] MpsActivatorO EXECUTING GETTING MSG-action [RUNNING] 
P:10 

23 [0001.4000] MpsActivatorO CHARGING 0.0016897916793823242 

24 [0001.4000] MpsActivatorO delayedDelivery 1.4016897916793822 

25 [0001.4017] MpsActivatorO TH3 to MpsActivatorO S[GETTING MSG,RUN¬ 
NING] p:10 t:l.4016897916793822 delivered 

26 [0001.4017] MpsActivatorO EXECUTING ACTIVATE-action [RUNNING] P:10 

27 [0001.4017] Plato WAITING: %g TK_A1(Plato) to Token A 
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